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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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??

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:

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:

COMMANDS

• 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.

FUNCTIONS

• 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.

OTHER

• 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.

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.

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.

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.

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.

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.