Welcome to Rich's Sparky eZX BASIC Project News
|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
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
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
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
|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
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
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
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
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
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
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:
- Change the SEA Change ROM source code to be
ZMASM (ZDS) compliant. This may take a week or so.
- 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.
- Remove the existing network code, as no such
hardware for Spectrum networking will ever be made available.
- Replace the RS232 code with the previous Sparky
- Add the interrupt table from the previous
- Remove the keyboard specific code as the RS232
console and interrupt code handle all key specific input now.
- Replace the BEEP and BEEPER code for Sparky
specific operation (perhaps change the timer model to make for more
accurate sound generation).
- Add all of the rest of the Sparky specific code
and system variables where needed.
- Power it up and see if it works!
- 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.
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!
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
- 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:
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.
You can always add more
||1 MB SRAM
This is where the system
RAM starts for program and variables.
There is 9K of high
speed SRAM available in the eZ80 for use. This is perfect for
the system variables.
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.
||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.
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.
The MAC address for the
EMAC interface. It also resides in protected memory.
||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
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
- 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
- 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
- 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:
- 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.
- 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
- 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
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.
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:
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.
|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.
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
- 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
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.