ZXmore or the ZX80CORE follow-up

[1024MAK]

Looks great! .

"I liked the" ZXmore "so much, I bought the company". Well, actually, I ordered and paid for one ZXmore today

Mark

[PokeMon]

"I liked the" ZXmore "so much, I bought the company". Well, actually, I ordered and paid for one ZXmore today

That would be cheaper than Apple (not apple).

[PokeMon]

Okay, some news good and bad for you.
The bad one is, there will be a small delay in delivering as I got an idea to improve the system. The good is, you get a better ZXmore.
I need a new/bigger CPLD for that and change the already programmed EPM3032 against EPM3064 with 64 macrocells instead of 32.
The 32 are now used to 100%.

Yesterday I took a look in the sources of the ZX Spectrum ROM and found out, that the AF' register is not reserved for use in the NMI routine but used several times in the code, mainly during SAVE and LOAD but for other purposes as well. This conflicts with the usage now as margin line counter. I could fix this behaviour by patching some rom locations and replace EX AF,AF' instructions with corresponding PUSH AF / POP AF combinations but I fear that this instruction may be used in user programs/applications as well.

Thinking further there might be CP/M applications as well using the AF' register. My display routines don't use IX and IY register anymore but still use AF' register for the 55 or 31 margin lines depending on PAL/NTSC mode. So to get rid of this register I could use a variable in memory as well but it would take much more time in the NMI routine to switch the latches to instance 0 and back which would slow down the speed of the ZXmore. I now have the idea to replace the 55 NMI's plus 1 sync NMI with just 2 NMI's and have a long period of 55*64us=3.5ms with uninterrupted time for application and one fast NMI with 64us for synching the display. This would in the end fasten up the whole machine as I don't need to decrease a counter at all and let this job do the CPLD.

Luckily all signals needed are present and I just need about 16 additional macrocells to setup a 6 bit binary and partly programmable counter and a changed NMI handling - that's it. This won't need any changes in the already fixed firmware 0.9 and is a hidden feature activated with the next release. I just need the other chips and play around a few hours to test this feature which is not activated by default (or set to one hsync per NMI).

I think this feature is worth to wait a few days more and just ask for your patience.
The other option would be to do a hardware update with the next release but I don't like that and would be much more complicate.
I think this would be the last programmed option.

I like the CPLD quite much and it saved my bacon with easy change of business logic when desired later. I am still not convinced that it is a good idea to do all in a CPLD as there are only 34 signals available but can put quite much logic inside. Luckily the 64 macrocell CPLD has the same case and pinout.

[1024MAK]

Hi PokeMon

That sounds like a "good" reason to wait.

So no problem

Mark

[PokeMon]

So finished work now with the new CPLDs and now I can switch between standard 2x 55 NMI's per frame or just 2x 2 NMI's while the first one occurs after 53 hsyncs (so as no. 54) and one short one for synchronization. This will make the usage of AF' register obsolete in the next (!) software release - not in the first one. This was a plain feasibility study. Default behaviour is 55 NMI's, the feature has to be activated by software. So the shipments will go out tomorrow then finally. And yes - this is implemented for NTSC as well with 31 NMI's or the first NMI is 30 hsyncs long plus one sync NMI.

I did test the picture on a 42 inch plasma TV with great crispy picture as expected.

All in all it got quite faster as there is no time waisted anymore during counting NMI's. This is done inside the CPLD now.

Standard ZX81 = 100%
ZXmore with 3.25 MHz = 116% (Revision 1)
ZXmore with 6.5 MHz = 234% (Revision 1)
ZXmore with 3.25 MHz = 135% (Revision 2)
ZXmore with 6.5 MHz = 272% (Revision 2)

The first speed difference 116% vs. 100% is just the implemented NMI WAIT stuff (wait only in the last sync NMI).
The second speed difference 135% vs. 100% is when NMI's reduced to just 2 NMI's (compressed NMI handling).
So you can see how much time is wasted in the NMI concept.
The 6.5 MHz give just double speed on request - can be choosen per instance and changed anytime.

So the ZXmore is quite fast now.

3.25 MHz

IMG_8619k.JPG (121.73 KiB) Viewed 3566 times

6.5 MHz

IMG_8618k.JPG (117.1 KiB) Viewed 3566 times

[PokeMon]

So finally - here is the first part of documentation, an instruction manual for completing the construction kit of ZXmore.
Also added here the schematics for debug purposes.

ZXmore-V11-ConstructionKit.pdf

(1.12 MiB) Downloaded 282 times

ZXmore-V11- Schematic.pdf

(300.37 KiB) Downloaded 304 times

A second manual as "ZXmore user manual" for working with the ZXmore will be released soon as well.
You can expect the listings at sellmyretro tomorrow.
Have fun.

[1024MAK]

Thank you

Mark

[PokeMon]

One more thing - please pay attention when soldering the PLCC socket into the board - it has a diagonal corner which has to match the marking at the board.
You maybe have to look twice.

I did test with some different USB flash sticks and found out that the current consumption is quite different.
The ZXmore takes about 90 mA when connected to a monitor or TV (12-13 mA used from the TV on 75R).
The stick I tested all the time takes 60 mA additionally. This is quite much.
I now have a very small nice stick which consumpts only half of it (30mA).

So depends on what medium you would take.

IMG_8623k.JPG (154.38 KiB) Viewed 3513 times

I strongly recommend to use a dedicated flash stick and not with important data as I can not assure that data could be destroyed under strange circumstances. I don't think that this will ever happen but if you remove a stick when written on or something I can not guarantee what will happen.

[1024MAK]

I strongly recommend to use a dedicated flash stick and not with important data as I can not assure that data could be destroyed under strange circumstances. I don't think that this will ever happen but if you remove a stick when written on or something I can not guarantee what will happen.

A bit like Windows then

I have noticed that some USB flash memory sticks run warmer than others. Had not thought about measuring the current though.

Oh, and I have received a package from you, just not found time to open it . Having only recently got home from a late turn shift.

Mark

[PokeMon]

You will always have to take care about possible data loss on any machine.
Nobody really guarantees for data and the driver code I use to communicate with the USB flash medium is not from me (libraries from FTDI) and ofcourse can there be any software problem inside any USB flash medium - you never know. I just don't want to be responsible for irresponsible handling with personal important data.