Welcome to the Sparky eZX BASIC Project Web Site

 This web site is updated every time there is a significant change to warrant news.

Contrary to unreliable sources elsewhere, the Sparky eZX BASIC project is alive and well and welcome to all who wish to contribute.  However, I have not been able to work on Sparky for over a year now and I hope to be able to complete this project eventually.  I would rather have some more people involved to help alleviate the burden.

WANTED

  • Spectrum or TS2068 Enthusiast that would like to see the next generation the ZX design can be pushed to.
  • Circuit Board Layout Designer that could accurately design a PC board to piggy-back on the eZ80 trainer board for use as the display card for the project.
  • FPGA Programmer (or equivalently experienced hobbyist) who has the ability to work with FPGA chps to create an advanced video interface/display chip.
  • eZ80 (or Z80) Assembly Programmer who is willing to help convert the 16 bit addressing code in the Spectrum ROM code into a 24 bit address space.  This means expanding the BASIC address space to the full 24 bit address space of the eZ80 chip.  Contact me for further details.  You have 1 megabyte of ROM code space to work with, so don't be shy.  I anticipate the math code will be the toughest to convert.

THANK YOU

I say Thank you to the following people for their help and contributions:

  • Andrew Owen - A fan of all things ZX Spectrum and has been given stewardship authority over Amstrad's Spectrum ROM code.  He's in charge of the open source SE BASIC project which is intended to improve the existing Spectrum ROM and yet maintain existing software compatibility.  Currently the project focuses on the 48K Spectrum, but also benefits the 128K series.  Go and check out his Spectrum SE hardware project as well.  Where he now has some pictures!

  • Geoff Wearmouth - For his absolutely magnificent work on the SEA Change ROM code.  This guy must live and breath Spectrum to be able to do this great work.  The goal of his project is to make the ROM code the way he believes Sinclair originally intended it to be with full streams support etc.

NEWS
Latest:  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.
Click here to read the news archives