Welcome to Rich's Sparky eZX BASIC Project News Archives

July 9, 2007

I've decided to code a hardware emulator before building a prototype.  I'm not interested in speed, but accuracy of the display output.  This will allow me to make quick changes to the OS without having to program the flash rom, dump the memory, and convert it for display.

I'll code it in Perl, as it is very forgiving and slow enough to follow what's happening in the OS.  Besides, it saves more time not having to compile/link over and over.

March 16, 2005
Work has been moving right along.  Since nobody is interested in helping out, the work is going slowly.  No matter, it's a fun project for one.

I have been lacking in updating the web site, although the project is progressing quite well.  The OS has reached 256K so far and still has room to grow.  The hardware design has changed a bit.  Whereas I thought to not implement bank selecting on a CPU capable of addressing 16 Megabytes of RAM, I have designed the memory bus a little uniquely.  The display hardware will be on it's own completely isolated 4 megabyte / 22 bit memory bus, and the CPU can access this memory by banking out the top 4 megabytes of RAM to draw to the display.

This configuration solves many problems:

  • It gives a means to allow the display and CPU to run at full speed without the need to stop the CPU when the display needs access to display memory.  However, only when the display RAM is banked out.  This is achieved by using a bi-directional tri-state buss between the CPU and display hardware.  This also allows for greater display resolutions and colors.

The OS buffers all drawing commands and does not actually draw them until the vertical blank interrupt is received.  It then draws all of the commands in the buffer and returns.  This is a crude form of display buss arbitration and it seems to work seamlessly.

October 30, 2004
I have had some ideas on how to implement display hardware without having to step on the CPU's toes.  The lack of the ability to hold the clock signal of the CPU high to mimic the Spectrum's method of display arbitration is out of the question for the eZ80 CPU, as it needs to run its clock constantly and gets very upset when it stops.  There is also the problem of no WAIT signal from the eZ80 CPU, and thus you can't just tri-state buffer the display RAM and hold WAIT until the display is finished with.  The only is to do one or a combination of the following:
  • Have BUSREQ asserted at the beginning of a scan line, but leave enough of a border (at least 10 clock cycles) to give the CPU time to finish accessing the address bus to tri-state it before the display hardware actually starts spitting out pixels.  This means a lot of timer triggered timers will need to be used for this to work.
  • Have dual-ported RAM be used for the display RAM.  Dual ported RAM is not easy to locate these days, but it may be worth the hassle of a larger PC board simply because this would allow the CPU to always be running without having to stop the bus for display writing and reading.
  • I could do the method the Motorola chip did and isolated the display memory from the CPU bus and read and write to the display via special registers.  This, however, may be slower and more complicated than necessary anyway.

If I can just get a working prototype ready, I'll be able to concentrate on getting the OS developed for it.

September 10, 2004
I have advertised for FPGA programmers to help in making a SVGA video generator for the project.  I noticed that the Opencores web site has available an extremely nice SVGA video core.  Perhaps it could be modified to make it eZ80 friendly and have Spectrum like display modes as well.  I'm not an FPGA expert, so I have no idea on how flexible they can be.  What's important for this is to not go overboard with display capability.  Preferably something that uses less than 1 megabyte of RAM and can be interfaced to an 8 bit data buss.

Even though the 50 MHz eZ80 is about 48 times faster than a 4 MHz Z80, it would be best to avoid complicated video output.  Perhaps 1024x768 should be the highest resolution.  This mainly to leave enough space for program code as the eZ80 only addresses 16 megabytes of memory.

August 1, 2004
After a long hiatus this project is back on line!  A lot has happened since November 2002.  Unfortunately, nothing has happened on this project.  However, I intend to bring this project to higher visibility to, hopefully, recruit more to be involved in it.

If you want to join this project, then please contact me.

I have decided to improve the hardware specifications in hopes of being able to use a programmable array device to generate video and perhaps be much like a ULA to the new design.  See the specifications page to learn more about the upgrades.

November 30, 2002
I am a member of the eZ80 users group and have been trying to get their link to this site changed for quite some time, but even though I'd get a message from the group leader saying "ok, it's changed", I'd go to their web site and find the link the same.  I had given up trying to get it changed.  I suspect he sent the message and was meaning to do it, but it was somehow forgotten.  Nevertheless, today I saw someone else, that is a member of the email group, advertise this site as still being around via the email newsletter system!  Now that makes me happy.
November 22, 2002
You may have noticed that I haven't posted some new source code recently.  Do not despair, I'm still working on another release, but I'll only release it when it's ready.  I'm adding better peripheral and internal chip set up code.  Right now the eZ80 based code is a patchwork and I need to make it work right before I continue with OS improvements.

I have also made some changes to the web site (as you can tell).  I've decided to go to a frames based site as anyone that's going to view it I doubt will be using a WebTV.  Besides, it makes the footprint smaller and easier to fit into Sparky's flash ROM.  The Javascript should work fine on all browser platforms.  If it doesn't, then please let me know.

November 15, 2002
I got some information back from ZiLOG (not too helpful I must say) and they said the flasher maps the internal SRAM to that memory space (right on top of the FLASH memory) and uses it as a buffer.  How stupid is that?  I can think of many answers to that question.  Never mind though, as I have the source to the flasher and may modify it to behave properly.  Then I thought, "how is anyone else going to flash their system properly?"  So... I'll just leave that portion of memory alone for now and worry about it later.

I'm going through the code right now and debugging it up to full functionality to this point in development.  For some reason this version is not recognizing key presses.  Somehow I have a problem with the interrupt initialization somewhere.  Once it's fixed and all of the code is cleaned up to read better, I'll be going through the SE BASIC and SEA Change ROM code thoroughly to see if anything can be incorporated into the Sparky code base before those projects get way ahead of me.

Just for fun, I have Sparky feeding the sample web site by ZiLOG that comes with the development kit.  If you would like to see it in action, then click here.  It will only work when I'm not developing code.  Maybe I'll put a copy of this site on it some time soon.

November 11, 2002
I have thought of a temporary solution.  I'll just overwrite the flash code in the ROM and use a ZPAK based flasher.  I suspect the problems with flashing are a direct result of the internal memory being mapped at the problem addresses in the flash code (they forgot to move it out of the way).  Nevertheless, instead of the ROM code starting at $008000 as documented, it will start at $000000.  Which should give room for a flasher update from ZiLOG.

I have decided to approach the 16 to 24 bit addressing one routine at a time, starting with the executive routines.  That way I can see things slowly working from the boot on up to eventual full functionality.

I recently read an article on the comp.sys.sinclair news group that said a group of people wanted to design a virtual computer based upon an enhanced software Z80 emulator and an enhanced ZX OS.  This computer would only exist as an emulator that emulated something that does not exist.  They claim they have an enhanced Z80 software core capable of addressing 4 gigs of RAM and an enhanced instruction set to support it as well.  They want to convert the Spectrum OS to work with this new software PC.  They have nifty software, GUI, and game ideas for it, which all sound fine and dandy.

This all sounds great on paper, but I do not think they realize how complicated such a conversion will be to make the ZX OS 32 bit compliant.  I'm having a difficult time converting it to a 24 bit model as it is for a real processor.  I'd like to see how they get it done for a processor that doesn't exist!  Everything in the ZX OS is heavily 16 bit dependant.  I am finding many routines will have to be rewritten just to pull the OS out of that limitation.

The BASIC program line layout will require upgrading.  Variables will require improvements from a 16 bit size limitation to one much larger.  Arrays throw an even bigger monkey wrench into the mix as well.  Line numbers for the BASIC will have to be allowed greater than 16383 lines.  With such a great memory base, the format of command and function tokens will also have to be expanded to make room for greater functionality.

Making a "compatibility" mode would be ridiculous considering the differences.  People would be better off just loading a true Spectrum emulator in another window.

These obstacles are not impossible for the Sparky project, but I wonder if the people in this other project are aware of how much more difficult things will be for them.

November 8, 2002
A big problem has arisen.  I had attempted to dump a version of the code to the flash ROM of the eZ80 evaluation board.  It seems the locations from DC00 to FFFF are not getting programmed or erased.  I have made a report with ZiLOG technical support hoping to get this situation remedied.  I'm hoping that this is a problem with the flashing software and not with the hardware itself.  If it is a software problem, then hopefully a fix can be given quickly.  If this is a hardware problem, then there may be a delay in development until a replacement can be received.
November 6, 2002
Oh my word!  Andrew Owen has made a generous contribution to the project!  He has designed a magnificent boot screen for Sparky, and I have placed it on the home page for all to see.  He has somehow successfully created the illusion of a rainbow gradient in the limited color space of the Spectrum screen (Which Sparky will use as its default boot screen mode).  It is absolutely marvelous.

I am still modifying the code to work in 24 bit register and addressing mode.  I'm through most of the sections, but am getting close to the hard stuff, and I have no idea how long it will take me to get it to a point for testing.  I'm hoping to have the display hardware ready for testing.

In addition to the memory map on the Specifications page, I have also put in the I/O map as well.

I have also figured out how to make the graphics routines streams obedient.  I am just going to use the currently unused lower control characters for graphics output.  That way the device's driver can handle graphics output any way it wishes.  Also, due to the resolution enhancements, the COORDS variables will be extended to 24 bits (only using 16bits each though) for X and Y.  This will allow compatibility for all graphics routines including the legacy ones.  More explanations will be given in the source files when implemented.

November 3, 2002
The project has gone into the heavy modification stage now.  It will be quite a while now before a new working version will be available.  This is simply because I am now converting the code, section by section, in 24 bit addressing mode.  While it may sound simple on the surface, it's not really.  There are a lot of routines that exchange double register values via the top and bottom registers.  Now that there is a new high byte in the long registers, this technique will have to be changed.  Sure, it would be simpler if ZiLOG made the highest byte of the long registers directly accessible, but alas they have not.  So pushing and popping will have to be the shortcut to register swapping.

There are a few sections that will not require modification as they appear to operate quite fine in long address mode as they are.  I intend to get the screen and boot related sections done first so a debugging platform can be had with partial working code and screen output.

October 24, 2002
The new project source file is ready for downloading from the Specifications page.  You should now be able to load it as a project in the ZDS environment without the need of configuration etc.  You may have to tell it to auto-configure it for the new location you are placing it.

Some minor changes have been implemented.  The step-over byte in any tables has been removed as it was stupid anyway.

October 23, 2002
I have finished converting Andrew Owen's ROM code for him.  He seems pleased and has already added some code improvements to it, like programmable macro keys.  I considered implementing macros, but I immediately realized that can be a RS232 terminal feature and is not really needed in the ROM code, at least for now.

I am in the process of converting the ROM routines into separately included source files to make editing much easier, especially when attempting to convert code Andrew or Geoff has improved upon.

Before I move headlong into further coding, I want to see the differences in routines between what is already in the Sparky code base and what improvements or bug fixes may apply from Andrew and Geoff's code.  This may take a week, but it should be worthwhile.  Once all of that is done, I will be changing the way you download the source code.  I'll be packaging it up with all of the required files to load it into ZDS without configuration etc.  This should make it easier for those not familiar (yet) with using ZDS, but want to get tinkering with the code.  Until that is ready, follow the instructions in the Specifications page.

You may have noticed, that for the time being, I have moved the RAM starting address up to $6000.  This is only due to unknown display code corrupting the font in the ROM space for some reason.  I suspect it is in the CLS routines somewhere.  Until I fix it, the display will remain at $6000 instead of $4000 for now.  This all is unimportant for the end result as the display will be at the top of the eZ80 memory map anyway when all is said and done.  However, for now, and debugging purposes, that's where the display lies.

Is anyone interested in writing a quick little boot up tune for Sparky?  Currently Sparky just beeps twice when booting up.  I'd rather have a short 6-12 note tune play when it boots.  I was also interested in another tune signifying successful program completion instead of the single beep tone.  I'd prefer a simple tune keeping to the same basic octave of notes.

October 18, 2002
Ok, work will start again soon now.  I am making progress on Andrew Owen's version of SE BASIC that I volunteered to label for him.  I should have it complete by early next week at the latest.

In the mean time, I have posted a direct dump of the screen memory to show what it looks like when you boot up the system.  This screen looks horrible on the RS232 console as it is only ANSI, but looks magnificent for graphics display, which is the end goal anyway.  So who cares what it looks like on the RS232 console.  It will change in the end anyway, as the console will be exclusively for the editor and program input and the screen will be for the program output.  Kind of like the old Atari 8 bit machines.

If you have a better idea for a boot screen, then please let me know.  There is plenty of ROM space and should not be an issue to implement no matter how complicated it is.  Keep in mind, however, the screen format must be compliant with the Spectrum's 256x192 screen and attribute layout and limitations.  Direct screen dumps as graphic data are possible if you want to draw it on your Spectrum and submit it as an SCR file.

October 15, 2002
I have offered to help Andrew Owen in labeling his code properly to make editing much easier.  This is what I'll most likely be doing for the next week or so to make up for time to wait on the SEA Change ROM.  However, things are looking a bit weird for SEA Change now.  The SEA Change ROM has a nice and powerful set of streams code, BUT all drivers are hard coded into the system.  According to Andrew Owen, the SE BASIC ROM will be able to load external drivers dynamically and everything will be streams driven for true relocatability.

This brings forth a dilemma, Geoff Wearmouth's SEA Change ROM is extremely well optimized in relation to all of the routines fitting in a small space.  In other words, it's extremely well compacted with a lot of features added.  On the other hand, Andrew Owen's SE BASIC ROM promises to be more hardware independent in its final state with an even better streams model than the SEA has.  Decisions...decisions....

I have an idea, which may work if done carefully.  Instead of having one large and gigantic source file for the OS in Sparky, the various portions of the OS will be divided into different source files that are included into the main source to allow for easy changes as they arrive in the other versions available.  So, as soon as the SEA Change ROM is stable the Sparky Project will resume, and when either the SEA Change ROM or SE BASIC ROM has a change or addition warranting an upgrade, then they will be implemented as necessary using the SEA Change ROM as the original code base.

So here's how things will go:

  1. Change the SEA Change ROM source code to be ZMASM (ZDS) compliant.  This may take a week or so.
  2. Re-organize the code to be properly organized according to their specific function.  SEA Change has code shoe-horned all over the place to make room for everything to fit in a 16K space.  Since Sparky has 1Meg of ROM space, this is not currently a problem (and probably never will be) and thus organizing the routines in order will be very important.
  3. Remove the existing network code, as no such hardware for Spectrum networking will ever be made available.
  4. Replace the RS232 code with the previous Sparky specific code.
  5. Add the interrupt table from the previous Sparky code.
  6. Remove the keyboard specific code as the RS232 console and interrupt code handle all key specific input now.
  7. Replace the BEEP and BEEPER code for Sparky specific operation (perhaps change the timer model to make for more accurate sound generation).
  8. Add all of the rest of the Sparky specific code and system variables where needed.
  9. Power it up and see if it works!
  10. If all goes well, then separate each code segment into separate files to be included into the main code segment.
October 11, 2002
Andrew Owen has done it again.  He has released a translated version of the Spanish ROM-0 of the Spanish Spectrum 128.  The editor within this ROM code is magnificent and would be the perfect code to include in the Sparky project.  Unfortunately Andrew is on vacation and will not be back until next week.  Hopefully this code has commented source available for it as well, but we will not know until he gets back.  Much work will have to be done to make it work with Geoff Wearmouth's SEA Change ROM code in linear address form.

Friendly inquiries have been made to the Sprinter team in offering to assist in creating a new Sprinter based on the fast eZ80 processor.  So far the reaction has not been negative.  There is so much potential with the eZ80, that I am sure sales for a "super" Sprinter would increase.

There is one thing I have noticed with all of the disassemblies of ROM code out on the Internet, and this includes Andrew's and Geoff's code.  What is this?  Well I have noticed that all labels for routines are merely numeric intended to point out the address of which it is running.  This is still far too difficult to read and follow when only a number is given for a CALL or JP.  This is not a good practice especially if one is trying to improve the code.  Geoff's code does use routine labels, and I applaud him for it, BUT he still uses hard addresses for system variables.  This makes code just as difficult to read as well.  Specific addresses for system variables can still be achieved with labels and complete labeling should be practiced by all of those modifying code for the Spectrum crowd.

You may have noticed, if you have been following this project, that the code I have converted from the original SE BASIC code, I had to spend hours converting numeric labels to their proper English counterparts, and also labeling the system variables.  This allows for insertion or relocation of the variables should it be desired, and makes the code all that much easier to read.  Why Andrew doesn't practice this helpful coding habit is not understandable to me, but I am sure he has his reasons.  Geoff gets there half way by labeling the subroutines, but neglects labeling the system variables.  Why??

October 7, 2002
After taking a long and hard look at the extremely excellent work that has resulted in the "SEA Change ROM" (SCR for short), I have decided to ditch the current source code and use the SCR as a base instead of the SE BASIC ROM (SEBR for short).  Why the heck am I doing this?  Well, the SCR has numerous improvements that essentially renders a lot of the original code obsolete (and makes my work a lot easier).  So much has changed from the original code, that it would be better to just modify the SCR much as was done with the SEBR code that I have been working on.  All of the improvements I had made to the previous code will, of course, be implemented in the new base, like the tokenizer and the RS232 code etc.  Despite what you may be thinking, this move will actually accelerate the development time for Sparky as all of the improvements in SCR were planned for Sparky.  Lucky for me, someone has already done them!

The SCR followed a much broader path that is better suited to the Sparky project than the SEBR project was.  You see, the SEBR project was designed to improve the old ROM, but maintain 100% compatibility with the old ROM.  Which Andrew Owen has done masterfully.  However, since the SCR project concentrates on only maximizing the capabilities of the ROM rather than software compatibility, it should work much better in this project.  A limiting factor, however, in the SCR project is ROM size, as fitting it in the 16K ROM space of the Spectrum is still a goal.  Whereas ROM space is not an issue here.

So, what happens next?  Well, not much until a more final version of the SCR is made available as it seems to change so much from day to day it would be pointless to attempt to snag it now for use in Sparky.  As soon as all of the goals of the person in charge of the SCR have been satisfied and the code appears stable, I will then move it to Sparky and begin to revamp it for use with the eZ80 and such much as I did with the SEBR.

The plan, once SCR is stable, is to do the following:

  • Replace the BEEP and BEEPER routines to match the eZ80 specific ones in the original Sparky source code.
  • Replace the keyboard routines with the proper RS232 handlers as in the original source, but the second RS232 channel will have to be opened first unlike the current code.
  • Make the "K" stream have an output routine and remove the bottom screen code from the "S" stream; and expand the "S" stream to a full 24 lines.  The "K" stream will output to the RS232 console for line editing and entry without the usual reprinting of the edit line on every keypress too.  This will have the effect of the "S" channel being a graphics channel for program output and a text only channel for editing.  This should actually simplify the code as the "K" channel doesn't have to worry about scrolling, cursors, etc.  It can just think of the edit line as one long string instead of worrying about column and row positions and size, etc.  The "S" stream can be further simplified by taking out the printer and lower screen portions of the code as well.
  • Each stream will have its own handler code and will not be co-mingled like the original "S" code was.  Yes, this made for compact code, but was too hardware specific.  When the screen hardware is installed, the different screen modes will also have their own handlers (drivers), which means the "S" stream will not be a system stream and will not be opened by default.  The Standard Output routines will be mapped to a default channel number (maybe #2), which should be opened to the proper screen handler before using the PRINT, PLOT, etc. routines.
  • Even though the "S" channel will have separate handlers for its output code, depending on resolution, all will use the "S" designation.  The OPEN # routine will determine which handler is installed by the string passed to it.  Once the screen modes are determined, the syntax will be given.

There is a down side to this.  The size of the code will be considerably larger than 16384 bytes.  Which means the code will have to be changed to work in ADL mode where appropriate, and the screen addresses will no longer be at $4000.  This means a lot of coding will have to be done before it is expected to work....ouch.  Here is the proposed new memory map:

Start End Title Description
FF0000 FFFFFF Display Hardware This top page is where the display hardware will be located.  Due to the possibility of problems with accessing the RAM at the same time as the display, special arbitration hardware will slow the CPU down if this memory is being accessed by the display hardware when the CPU is trying to access it.  Due to the unusual layout of the display, there may be extra and unused RAM available for use.
200000 FEFFFF Available for expansion You can always add more RAM here!
110000 1FFFFF 1 MB SRAM This is where the system RAM starts for program and variables.
10D000 10FFFF System Variables There is 9K of high speed SRAM available in the eZ80 for use.  This is perfect for the system variables.
100000 10CFFF Available for expansion Because the internal 9K of RAM of the eZ80 is mapped at the top of a 64K page, this lower space in the page is blank.  It could be used for extra memory mapped hardware if you wish.
008000 0FFFFF Sparky ROM Code This is where the heart of the ZX BASIC code is located, and is the location with which must be flashed to once assembled.  Don't worry about the restarts as the boot block code traps them and redirects them to their $0080xx counterparts.  In other words, RST 20 will be directed to address $008020.  Always remember that the interrupt index table must be in page 00 ($000000 - $00FFFF)!  Placing it immediately after the "restarts" would be wise.
004000 007FFF Boot Block Parameter Block This block is used for the boot block flasher and by the C based OS code, which is not used, but resides in protected memory anyway.
003FFA 003FFF MAC Address The MAC address for the EMAC interface.  It also resides in protected memory.
000000 003FF9 Boot Block Flasher This is specific to the ZiLOG eZ80 evaluation board and is required if you want to flash the ROM.  This is write protected memory thanks to jumper J2.
October 3, 2002
The streams code has been updated quite a bit.  Channel #3 is now permanently open to work with the Modem port.  It uses similar code as the Console port, but is not translated at all.  It is strictly a binary RS232 channel.  A new error message has been added, "Channel already closed" now shows if closing an already closed stream.

The FORMAT command now allows for changing the baud rate for both the console port (channel "K") and the Modem port (channel "M").  The format for the FORMAT command is as follows (and may change):

FORMAT "channel-letter:baud-rate-index" .  So the command - FORMAT "M:9" sets the modem port to 230400 bps.  The table for both ports are as follows:

 0 = 300 bps
 1 = 1200 bps
 2 = 2400 bps
 3 = 4800 bps
 4 = 9600 bps
 5 = 19200 bps
 6 = 38400 bps
 7 = 57600 bps
 8 = 115200 bps
 9 = 230400 bps
10 = 460800 bps

The FORMAT command might have the addition of flow control, stop bits, and word size soon also.  Nevertheless, the index format for setting the baud rate will remain.

When the screen hardware has been implemented, the FORMAT command will also be used to switch screen modes, and set up the system for output to it automatically.

The error handler has also been improved.  Instead of the typical single line an cryptic error messages of the Spectrum, you get three full lines of better explained errors.  The first line is the text describing the error.  The second line indicates which line it occurred on.  The last line indicates which statement within that line caused the error.  Also a RASP or buzz occurs on all program stopping errors.  If the "error" is the "Ready" error (indicating no error and successful program completion) a nice quick beep occurs.

The User defined Graphics have been removed and so has most of the code having to do with them.  The TOKENs now use the full 128 character region from 128-255.  Since the font can be relocated, and the screen is going to be graphics only.  A quick change to an different font when printing user defined characters will be easy, and thus UDG's are not necessary code.  As a result of this, the block graphics characters are also not used any more.  Due to the unusual grouping of the commands and functions, coding to add functions should be easier than coding to add commands.  For commands, rather than shifting the functions up, it might be easier to just patch the code that checks for a command code.

Speaking of additions, the following are considered for the future:


  • FONT - Simply pass this command an address and the font pointer is changed.  Perhaps the function "RESET" might be also used to restore the original font.
  • ON ERROR - Careful dissection of the TS2068 ROM will make this command possible.  Such variants will be "ON ERROR GOTO", "ON ERROR CONTINUE", and "ON ERROR RESET", much the same as on the Timex.
  • COPY - This is NOT the screen dump COPY, which has already been removed as how many ZX Printers are there now days??  No, this COPY will do double duty.  First it will just be a memory copy routine taking three numbers as input.  "COPY source, destination, count" will be the syntax for memory copy routines.  Disk copying will be determined at a later date.
  • LPEEK - Since we have DPEEK, which returns a 16 bit value from an address, why not return a 24 bit value via LPEEK?  The eZ80 has 24 bit addressing and retrieving 24 bit numbers will be necessary.
  • PEEK - Since the original PEEK was removed and replaced with DPEEK, PEEK will be restored and DPEEK moved as a new function.  Actually, all three peek commands will be handled by the same routine to save space, except it will be smart enough to know what kind of a PEEK to perform and return the correct result.
  • Corresponding LPOKE, DPOKE, and POKEs as well.
  • BOX - This will draw a box on the screen.  The box will be drawn from the last plotted position and will have a simple syntax, "BOX width, height", that's it.  It should be simple to code and implement.  It will essentially be a series of DRAW commands.
  • SLEEP - The eZ80 CPU has a sleep feature.  Why not give this feature to BASIC?  It will be similar to PAUSE, except it waits for a specific event rather than a timeout or keypress.
  • DELETE - This will delete BASIC lines specified by the operands.  The syntax is identical as on the TS2068.
  • RENUMBER - The operand will give the step count for renumbering.
  • WHILE / WEND - Only when most of the other additions are inserted will this handy syntax be added.
  • BLIT - This will copy a boxed region of the screen to another portion of the screen with exact pixel accuracy.  Don't count on this routine until the graphics hardware is implemented for easy debugging.  The syntax will most likely be:
    "BLIT sourcex,sourcey,sourcewidth,sourceheight,destinationx,destinationy"
  • SAMPLE - This will sample input from the A/D converters.  Syntax is yet to be decided.


  • HEX - Returns a hexadecimal string for a given integer (decimal) value.  The limit will be a six digit (24 bit) string.
  • OCTAL - Returns an octal hexadecimal string for a given integer (decimal) value.  The limit will be a nine digit string (24 bit).
  • USED - This is the opposite of the FREE function.  It shows how much memory is being used.
  • XMOUSE - This returns the X position of the mouse (whenever an interface is designed).
  • YMOUSE - This returns the Y position of the mouse.
  • XJOY - This will return the analog joystick X value (0-255)
  • YJOY - This will return the analog joystick Y value (0-255)
  • BUTTON - This will return the joystick's buttons states.
  • XTOUCH - If ever a touch screen is installed, this command will return the X position value.
  • YTOUCH - This will return the Y position value for a touch screen.


  • Graphics clipping will be the default instead of getting that nasty "Out of screen" error.  Pixels off of the screen are just not drawn at all.  This will allow for partial circles and partial boxes, etc.
September 24, 2002

A lot of changes have been happening lately.  They are:

  • All indexing tables now point to a jump table which then points to the corresponding routine.  This eliminates the code size limitation on some portions of the code.
  • The assembler variable called "RESTARTS" has been added to debug the removal of the RST op-codes and replace them with the CALL instruction.  If RESTARTS = 1, then the original RST instruction is used, but if it equals 0, then the CALL instruction is used.  For some weird reason, this simple change is not working, and I've got a lot of debugging to do before figuring out what is corking up the works.  If you have any ideas, then I'd be most appreciative of any assistance you can offer.
  • The reason why the previous part of the project is being done is to eliminate the need for the code to run at the bottom of the memory map.  I'd much rather it run at %008000 in the 24 bit address space of the eZ80 instead of %000000.  That, of course, is the next part of the project, to convert the legacy 16 bit addressing of the code to 24 bit addressing and storage.  It won't be easy, but it has to be done before any more additions and changes are made to the code (in my opinion).  This will be a major undertaking.

    I have already started to convert the code one routine at a time, but still preserving the original Z80 code.  How?  Well I added an assembler directive called "COMPATIBILITY" and when it equals one it assembles the old code.  Otherwise it will assemble the new code.  This is mainly for the ability to better see the before and after effects of the changes, and to maintain a working "control" for the project.
September 17, 2002

I have fixed a major goof up in the RS232 buffering routines.  This goof up was that I originally coded the buffer to be a LIFO buffer instead of a FIFO buffer which it should have been.  Well, that's been fixed.

I have also fixed the problem with tokenizing the "<=", ">=", and "<>" characters.  I had received the tokenizer code from Andrew Owen of the SE BASIC project.  Unfortunately the code was uncommented, it also jumped around so much within it self, that I gave up on trying to fix the problem.  So.... I just custom coded a secondary tokenizer for just those codes.  This secondary routine uses the keyboard (RS232) buffer for inserting the proper token.  So, now tokenization is now excellent.

The RS232 routines should now be working great now.  I am sure I'll be making some tweaks and optimizations to it periodically to speed it up and make it as fast as possible.  The buffer is now 255 characters and the interrupt routine is now called when the UART FIFO is up to 8 characters.  I used to have it set to 14 characters, but it seemed to have dropouts despite RTS/CTS handshaking, so I reduced the trigger to 8 characters.  This is actually great considering the FIFO will still fill up to 16 characters.  So the interrupt routine is able to quickly dump the FIFO to the system buffer before the FIFO back fills.  In other words I have increased the throughput.

September 11, 2002

Ok, I've been working hard on the RS232 routines.  I am slowly getting the hang of FIFO based serial programming.  Soon I should be able to have error free transmissions at very high speeds.  The system defaults to 236400 bps now for the purposes of this testing.  If your PC cannot go that fast, then don't despair, just go to the "RS_INIT" routine and put in the value "%0016" for the UART0 baud rate and that should slow it to 115200bps.  Most computers should be able to handle this rate without trouble.

I am having a problem getting the logic right for RTS/CTS handshaking.  Right now I just toggle if a 128 byte internal input buffer begins to get full, but it seems that does not work as designed.  It works great for average speed data, but on really fast almost "bursting" data streams it seems the handshaking gets too slow.  Since the UART has a 14 byte FIFO, I think I'll just toggle RTS at every FIFO dump in addition to checking the buffer size of the main RS232 buffer.  This should make reliability greater.

Once I get those routines working as well as I can think, then perhaps I'll experiment with using the DMA controller and RS232 data retrieval.  No guarantees though.  Let's just see what happens with this next bought of programming.

Since the entire way of reading keys had to be modified, it still has some bugs.  BREAK is simply a CTRL-C, but use it sparingly.  I am thinking about using a GPIO bit as a break interrupt instead of the keyboard.  The keyboard is just too funky to have the BREAK sequence handled in the key routines any more.

On a slightly different topic.  Does anyone have a utility for Windows XP that allows me to "see" all of the RS232 line's status at real time?  It would be nice to see if the RTS/CTS handshaking is doing what I am hoping it is doing.  Yes, I could go and get a nifty RS232 status device from Radio Shack (Tandy Electronics), but I'd prefer looking at less expensive options at the moment.

September 8, 2002

I made the RS232 screen routines a lot more friendly.  The bottom screen is now on the top and the permanent attributes now work.  Soon to come are temporary attributes also.

The BEEPER and BEEP routines have been completely recoded.  BEEP is still "BEEP duration,pitch" but the numeric values are different and are 16 bit integers only.  The duration is now in 1000ths of a second and the pitch is now PITCH=5000000/Frequency.

The BEEPER uses timer-1 and timer-2 for duration and pitch.  This means the routines depend on accurate timers and not relying upon the "T-States" of the processor.  The Z80 had predictable timing, but the eZ80 is far too different and too fast to rely upon T-States for timing.

The BEEPER uses bit 7 on GPIO port A.  Hooking that bit directly to your PC sound card's LINE input should give you a nice a crisp source.  I'd start with the volume low first as this is a pure square wave and some speakers could get very annoyed at a square wave if the volume is too high!

There are some new commands and functions.  The command "PLAY" will play a "song" based on a table of 16 bit values that are assembled as follows:

.word Pitch #1
.word Duration #1
.word Pitch #2
.word Duration #2 etc.

.word 0
.word 0

The double zeros mark the end of the "song".  When using play you simply pass it the 16 bit address of where the "song" table is located.  Sparky plays a quick "song" at boot up.

The command "COPY" has changed syntax.  It no longer is a printer command.  It will be a file command, and thus its syntax is now:

COPY "from","to"

Currently COPY just reports "Invalid Stream", but will eventually be a true file command.

The function "FRAMES" merely contains the value of the system variable "FRAMES" in its full 24 bit form.

The function "FREE" is exactly the same as in the Timex/Sinclair 2068.  It contains the amount of free memory left in the system for use.

September 6,2002
I'm still working on the RS232 input routines to translate the VT100 escape sequences into Spectrum key codes.  There's a lot of work to be done, but right now it "sort of" works.
September 1,2002

Well, after some hard work, I have been able to get a much modified version of the Sinclair Spectrum ROM to boot and to function!  It's pretty cool.  What I have done is this:

  • Fixed all of the bugs as indicated by various experts throughout the years.
  • Patched the screen print routines to echo to the RS232 console port on the eZ80 evaluation board.  All screen graphics and print routines still draw to the "display" at memory location 4000h, but until a compatible graphics display board is added it's pretty much useless.  It is intended to eventually have a fully color compatible VT100/ANSI display for 80% display duplication.
  • A tokenization routine has been added so all commands, functions, and keywords much be typed in.  Upper and lower case is not a problem.
  • The keyboard routines have been bypassed.  Instead a new RS232 routine for the console port on the eZ80 evaluation board now handles keyboard input.  These routines are far from complete, such as the arrow keys are not yet functional.  However, the goal is for complete translation like some Spectrum emulators have.
  • All cassette and ZX printer routines have been removed, as they are useless now days.
  • Since the eZ80 has no IM 0, IM 1, or IM 2 modes (now those commands are a NOP on the eZ80190 chip), an interrupt table has been incorporated into the ROM code for the eZ80 specific vectors.
  • The FRAMES counter was originally used to count the number of vertical interrupts that have been received since boot.  The code has now changed, since display hardware has not yet been added.  The FRAMES counter is just incremented every 100ms via its own interrupt routine.
  • The above keyboard routine is only called if a key is available in the RS232 UART, thus speeding up overall execution.

The plans for the future are to add in a memory management routine.  First the plan was to convert the 16 bit addressing of the Spectrum ROM into the new 24 bit mode of the eZ80, but the code was far too tightly dependant on 16 bit addresses and values.  The stack and such are always assumed to be 16 bits per push or pop.  Coding for ADL mode has just proving to be far too much a headache, most especially in the Spectrum calculator routines which are highly stack dependant.

So instead the extra memory will be used for variables storage and such (eventually).  Perhaps a RAM disk file system.  I don't know yet.