Shop OBEX P1 Docs P2 Docs Learn Events
ZiCog a Zilog Z80 emulator in 1 Cog — Parallax Forums

ZiCog a Zilog Z80 emulator in 1 Cog

heaterheater Posts: 3,370
edited 2013-07-31 16:04 in Propeller 1
ZiCog a Z80 emulator for the Propeller.

Run CP/M 2 and 3, Microsoft BASIC etc on a Propeller.

Latest version is zicog_v0.10.zip


The demise of the 4 COG Z80 emulator project was precipitated by the realization that it is possible to create a full up Z80 emulator that uses only one COG. Further that this emulator would be just as fast as the 4 COG effort, would be a lot more elegant and understandable than the old PropAltair 8080 emulator and would be far more friendly to external RAM.

How is this possible?

The classic way of building an emulator is to have a look up table that is used to get from a given instruction opcode to the function that will emulate that instruction. This is fine if you have a lot of space to put those instruction handler functions. In the Prop COGs there is not enough space. We could try to use more COGs. This is slow and wasteful of COGs.

Another emulator approach is to try and decode the various bit fields of the opcode and determine what the instructions data sources and destinations are and what operations should occur. In this way one can fold up the emulator into a twisted mess of code logic that will fit in a COG. This was how the first PropAltair 8080 emulator worked. It is slow.

A new approach: After looking at the emulation process long enough I came to the realization that most of the instructions boil down to three steps:
1) Get an operand from somewhere. The Source.
2) Do some operation with that operand and (mostly) the accumulator (The A register). The Operation.
3) Put the result somewhere. The Destination.

In the 8080 there are about 25 different sources and destinations: Registers A, B, C etc, memory via HL, memory via direct address, immediate data etc etc. There are about 30 different operations, ADD, SUB, ROT, INC, DEC etc etc.

All these sources, destinations and operations can be implemented in a from 2 to 20 lines of PASM each and they will all easily fit in a COG. All we need now is a way to connect different combinations of source, operation, destination together to implement each instruction.

This is where Cluso comes in. Who should, from now on, be referred to as "The Great Cluso".

Clusso suggests that one can put three COG addresses, vectors, in each LONG of a look up table, plus 5 bits of other possibly useful info. For a long time I wondered what such a clever thing could be used for. Until the euro dropped.

The first vector jumps us to a procedure to fetch the source info. The second vector gets us to some code to perform the operation and third vector takes care of posting the result to the right destination. This technique can also be used to take care of conditional/unconditional jumps, calls and returns.

Using this approach it is possible to fit a whole 8080 emulator in one COG with no LMM or other such junk and around 90 longs free!!

Turning to the Z80 we see that it has more than twice as many opcodes as the 8080 BUT looking closely we see there are only a handful more of those Source, Destination and Operation functions. Which can be coded as PASM in the free longs we have. The logic that ties them all together is in the dispatch tables in HUB.

Enough of the long lecture. My first pass at this idea is attached. I have not included the rest of the emulator files as this barely runs as it is but it does show the general outline. There is code in place for 90% of a Z80.

Early tests show that speed is nearly up to that of the 4 COG version, faster than the old PropAltair version and can be pushed a little more with some tweaks here and there.

It is early days yet but this file is intended to show what is coming for those who want to put CP/M on a Prop with external RAM or build some other emulator.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Post Edited (heater) : 8/19/2009 4:44:49 AM GMT
«13456741

Comments

  • TreeLabTreeLab Posts: 138
    edited 2009-02-28 02:34
    @Heater (and The Great Cluso) : Bravo, this is very clever. I especially like the heartbeat ...
    Can you give an estimate of the speed relative to a 4MHz Z80?

    Cheers!
    Paul Rowntree
  • heaterheater Posts: 3,370
    edited 2009-02-28 03:02
    Hmm... not so sure about actual Z80s. But an original Altair 8080 was running at about 350 thousand instructions per second (KIPS).

    This code has had only minimal testing so far but a loop of INR A, OUT 0, JMP 0000 runs at 384KIPS which happens to be the same as the 4 COG version and faster than the old PropAltair version of 348KIPS. I know I can push this to 400KIPS with a few tweaks. like putting some or all of the registers into COG space. I will probably not do that though, it complicates the code and makes the break, single step and trace debug features messier.

    Bear in mind that this may slow down when we start using external RAM so pushing too hard for little optimizations won't make much sense.

    That heartbeat is what I use to measure the speed using the FrequencyCounter object.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-02-28 03:12
    "z80_emu" is a very boring name and there is already such a project on the net. Should I call "PropZ80" or something? What about "ZiCog" ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-02-28 03:20
    Heater:

    It's a shame the 4 cog version didn't provide the gains you expected. Nice to see you are continuing the 1 cog version. Pleased to see the multiple vector approach is working (used this method in my undebugged spin interpreter to great effect).

    If you are not already using a 6.0MHz xtal, this·will give you an instant 20%.

    Hopefully, my TriBladeProp will be away to manufacture over the weekend - you will be surprised at the·extras I've done (no time to explain till it is away). Just taking a break.

    Keep up the excellent work·cool.gif·

    Postedit: PropZ80 sounds better - ZiCog is great but no-one will realise what it is.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps (SixBladeProp)
    · Prop Tools under Development or Completed (Index)
    · Emulators (Micros eg Altair, and Terminals eg VT100) - index
    · Search the Propeller forums (via Google)

    My cruising website is: ·www.bluemagic.biz
  • kwinnkwinn Posts: 8,697
    edited 2009-02-28 03:28
    Wow. That is one of the most impressive pieces of code an data structuring I have seen. I think both of you deserve "The great" accolade. I am truly impressed by the structure and elegance of it.
    As for the name, I like ZiCog. Somehow it seems to be in harmony with the "Propeller" spirit and way of doing things.
  • Mike HuseltonMike Huselton Posts: 746
    edited 2009-02-28 03:28
    Pemu.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    JMH
  • heaterheater Posts: 3,370
    edited 2009-02-28 03:50
    kwinn: Thank you. I think that's what they call "data driven programming" or at least "table driven"

    Anyway it should be in every "Software Engineering 101" course to identify your primitive operations first and then design the code to use them.

    It is fortuitous that the 8080/Z80 fits this scheme so well. We only have three vectors to play with in each table entry. With the 8080 you can get away with just "source", "operation" and "destination". As most operations work on the Accumulator (The A register) e.g. "ADD A, B" it does not need to specified in the table. Operations like "INR D" can work on any register/memory location, but here we only have one source and dest and they are always the same place.

    Had the 8080 been like some CPU architectures and have two sources and a destination like "ADD dest, src1, src2" we would be out of luck.

    James: "Pnut-Emu" What the..?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-02-28 03:51
    Ah "Pemu" that sound better [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Mike HuseltonMike Huselton Posts: 746
    edited 2009-02-28 05:06
    Glenlivet provided the inspiration...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    JMH
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-02-28 05:38
    What an awesome bit of code! For the rest of us - to quote Wayne's World, "we are not worthy"

    I was kind of hoping since we hadn't heard from you for a bit that you were deep in the world of coding. The new code is very elegant. Re the Z80 specific instructions, if you can do just LDIR I reckon it could do the N8VEM. How would the 64k memory interface (and could it use the cluso triblade?)
  • heaterheater Posts: 3,370
    edited 2009-02-28 09:13
    Dr_A: Na, it was nothing. Actually it is nothing, I would reserve the adjective "awesome" for the Linux kernel and such like.

    I have been deep in the world of getting myself work with a new start up, so my Propelling may have to slow down somewhat soon.

    LDIR, no problem I hope.

    For sure half the motivation for this "yet another total rewrite" is to accommodate external RAM interfaces. The old PropAltair version was squeezed to the limit making it hard to find room in the COG for external RAM interface code. The four COG version made the space available but at the cost of speed and COGs and HUB RAM. Not to mention the hassle of ensuring that only one COG access the RAM at a time.

    Cluso's TriBlade is the primary target platform just now and probably has the easiest requirements for adding external RAM driving code. Can't wait to get my hands on one.

    Mike Green has a serial RAM chip solution that while slower would be amazingly quick and simple to construct hardware wise. That kind of serial access requires more COG code to shift the bits but will now fit I hope.

    Leon has/had a board underway using an external RAM and a CPLD.

    @Mike and Leon: How are those RAM solutions going ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-02-28 10:38
    Heater teasing... The TriBladeProp can handle a pair of 512Kx8 (or pair of 2Mx8 if you can afford them) plus (not either/or) microSD plus 24C256/512/1024 plus SPI Flash 1-64Mbit on Blade #2. It has one onboard PropPlug. Almost complete - just adding some tracks and links for options - then to pour the ground and power planes smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps (SixBladeProp)
    · Prop Tools under Development or Completed (Index)
    · Emulators (Micros eg Altair, and Terminals eg VT100) - index
    · Search the Propeller forums (via Google)

    My cruising website is: ·www.bluemagic.biz
  • heaterheater Posts: 3,370
    edited 2009-02-28 11:00
    Good grief. Consider me teased [noparse]:)[/noparse]

    I'm sure CP/M with banked switched memory can't handle that much RAM.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-02-28 11:08
    I'm discovering things about the z80 that I'm not going to like.

    E.G. There is "RLCA" which rotates the accumulator setting only the carry flag like an 8080. Then there is RLC A which sets zero, sign, parity and carry!!!

    Things are going to get tight around here.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-02-28 11:11
    LDIR in 8080 code.

    PUSH PSW
    LDIR_LOOP:
    MOV A,M
    STAX D
    INX D
    INX H
    DCR C
    JNZ LDIR_LOOP
    DCR B
    JNZ LDIR_LOOP
    POP PSW
    RET

    That is fun - LDIR calls a list of 8080 instructions which calls a list of prop asm instructions. This would work though maybe there are some optimisations. LDIR is very useful for block moves eg getting a block of memory out of an eprom and into ram.

    Cluso, 512k eh? And all those mass storage options? Might have to look at rewriting some CP/M mass storage code. Keep it simple - if I sent you a number 0 to 1million can you send me a byte at that address? If yes (and I'm sure you can but I'm not an expert in how a prop might get a byte from a microSD), then CP/M can do the track-sector-to-address calculation. Then the microSD can become a disk drive within CP/M.

    CP/M only needs 64k. The rest could be useful for the prop but CP/M doesn't need it. Do smaller ram chips fit on the triblade?

    Post Edited (Dr_Acula (James Moxham)) : 2/28/2009 11:20:29 AM GMT
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-02-28 11:43
    Dr_A: Yes you can fit 128Kx8's but there is little price difference. The 512Kx8 are about $3. Only fit one. I was thinking the rest can be a RAM Floppy CP/M drive. Only one of the RAMs has the fastest access, the other has latched decoding.

    Sorry Heater - I didn't mean to hijack your thread.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps (SixBladeProp)
    · Prop Tools under Development or Completed (Index)
    · Emulators (Micros eg Altair, and Terminals eg VT100) - index
    · Search the Propeller forums (via Google)

    My cruising website is: ·www.bluemagic.biz
  • heaterheater Posts: 3,370
    edited 2009-02-28 12:40
    Dr_A: SD cards on the Prop for CP/M floppy and hard drives is already solved and done. Basically CP/M asks for sectors and we keep sectors in 512 byte blocks on SD card. (Or was it 256, I forget now). There is some wastage for the floppy disks that have 128 or so byte sectors but we can afford it in a 2GByte SD card[noparse]:)[/noparse]

    I will try and implement LDIR and friends as high speed PASM.

    I want those 2M RAMS. Good for a 1M RAM disk and possibly a smaller one as well. Latched decoding for a RAM disk is just fine.

    Cluso: You are by no means hijacking.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-02-28 14:11
    Was just fishing around to save some LONGs. In the process managed to get the single COGs increment register (INR B) and jump 0000 loop emulation up to 416KIPS.
    The 4 COG emulator only managed 414KIPS on that! I'm not depressed any more.

    70 odd LONGs free. Squeezing the the last of the Z80 stuff in without a little overlay cheating may be getting a bit tight.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • AleAle Posts: 2,363
    edited 2009-02-28 16:23
    heater: I saw that you picked a name already, great start.

    In the implementation of daa I think you could compare data_8 directly against 100 ($A0) without moving it to nibble and shifting it right 4 bits (line 517 of your v 0.0). The mux instructions sure were handy!
  • LawsonLawson Posts: 870
    edited 2009-02-28 16:40
    heater said...
    kwinn: Thank you. I think that's what they call "data driven programming" or at least "table driven"

    Anyway it should be in every "Software Engineering 101" course to identify your primitive operations first and then design the code to use them.

    It is fortuitous that the 8080/Z80 fits this scheme so well. We only have three vectors to play with in each table entry. With the 8080 you can get away with just "source", "operation" and "destination". As most operations work on the Accumulator (The A register) e.g. "ADD A, B" it does not need to specified in the table. Operations like "INR D" can work on any register/memory location, but here we only have one source and dest and they are always the same place.

    Had the 8080 been like some CPU architectures and have two sources and a destination like "ADD dest, src1, src2" we would be out of luck.

    James: "Pnut-Emu" What the..?

    I don't thing we'd be completely out of luck if 4 pointers were needed per op-code. In that case using four 8-bit pointers could work IF the missing bit could be implied. (i.e "banking" the code into low and high sections based on op-code sub part, or table pointers only go to even addresses) Otherwise, the 4th pointer could just be restricted to a 5-bit sub-section of a cog's address space. Could be a royal pain to get the compiler to do this automatically. (haven't dived that deep into assembly yet)

    Lawson

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Lunch cures all problems! have you had lunch?
  • heaterheater Posts: 3,370
    edited 2009-02-28 17:22
    I guess it might be possible under some circumstances. Say if you functions happily divide into four equal sized COG areas. Using even addresses only could waste a lot of LONGs if you have many functions. A five bit subsection is only 32 LONGS so would work for a few short functions.

    Hey, this thing gives me a big enough headache already[noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-03-01 20:08
    Attached is the Zicog Z80 emulator wrapped up in a demo which can be run on a PropDemo board using PropTerminal (Easily changed to keyboard and TV_Text).

    When the demo is run it shows the Z80 registers and steps through a short Z80 program loop when any key is hit. You can see the Z80 program in zicog_demo.spin.

    The main point here is to show that Z80 ops with prefix bytes (CD, DD, FD, ED) are handled with the appropriate dispatch tables being used.

    75% of the 8080 ops have been tested but only a handful of the Z80 ops. Almost all ops have some code in place but there is work to do on the Z80 flag settings.

    Despite my optimism it looks as if we are going to be a few LONGs short of getting everything in the COG. There are only 66 LONGs left. So somethings will have to be farmed out to LMM or overlay. However I will keep the Z80 string moves LDIR, LDDR and string seaches CPIR, CPDR as high speed PASM as they are the only Z80 ops known to be used regularly.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-03-04 16:37
    Once again I owe a huge debt of gratitude to Cluso. This time it is for his PASM overlay loader.

    ZiCog V0.1 (attached) has a version of the overlay loader shoehorned in where it is serving up overlays to handle the seldom used but long winded DAA instruction emulation. It is also catering for the 16 Z80 string move, compare, input and output instructions. LDIR and friends.

    Whilst I wanted to keep the string ops in resident PASM it turns out they become quite huge. Still this may be a happy compromise as the overhead of loading a short overlay for each string op is (hopefully) not so burdensome when moving/comparing long strings. Certainly much faster than using LMM.

    I have made some modifications to the overlay handler:
    1. The overlays parameters are stored in a table in HUB rather than in COG.
    2. Rather than use two instructions to load and execute each overlay I have arranged to have a single function do this, which is in turn called
    via vectors in the dispatch tables with a parameter indicating which overlay to execute from the HUB table.

    With these two changes any number of overlays can be used without eating additional COG space.

    The attached demo runs a program of misc Z80 ops. It nicely shows LDIR moving a code block from 0000 to 0100 where it is then executed.

    As usual any suggestions are welcome.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-03-04 18:30
    Heater: Glad it was useful for you smile.gif Can't wait to get my TriBladeProp running your ZiCog (and other emulations) smile.gif
    I asked about RED and it was going to cost an extra $2 per board - ouch! Obviously it's a pain for them to change.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps:· SixBladeProp, TriBladeProp
    · Prop Tools under Development or Completed (Index)
    · Emulators (Micros eg Altair, and Terminals eg VT100) - index
    · Search the Propeller forums (via Google)

    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • heaterheater Posts: 3,370
    edited 2009-03-04 18:55
    I hope I can get ZiCog to at least to run CP/M by the time you have your boards ready. Then ProAltair can have a virtual Z80 upgrade and you will be able to run WordStar in all it's glory on the TriBlade. And what I have been dreaming of for so long now, compiling C with the BDS C compiler.

    You know, ZiCog is not supposed to be happening. I always insisted that I did not want to make a full up Z80 emulator. It has just insinuated itself into my mind without me noticing. Now I won't rest until the EXZ80 cpu diagnostic runs flawlessly.

    Shame about the red.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • TreeLabTreeLab Posts: 138
    edited 2009-03-04 19:34
    @Heater;
    This is great. How far from 'working' is this version (as noted in zicog.spin)?

    I don't think that you can beat ZiCog as a project name for this [noparse]:)[/noparse]

    BTW : The MIT terms of use blurb was not in the two spin files ...

    Cheers!
    Paul Rowntree
  • GadgetmanGadgetman Posts: 2,436
    edited 2009-03-04 19:49
    @Heater, who cares about Wordstar?

    I think IBM did DB2 for CP/M...
    (Need to check what's in all those floppies that came with some of my CP/M machines... )

    smile.gif

    BTW: You are now officially way beyond what should be possible to do with a single COG...

    What's next?

    DEC PDP-11/750 ?

    wink.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
  • heaterheater Posts: 3,370
    edited 2009-03-04 19:51
    Depends what you mean by working[noparse];)[/noparse]

    I hope to have all 8080/8085 opcodes working and the T8080 CPU diagnostic passing within a week from now.

    Then I'll have to upgrade PropAltair to use this new emulator and get CP/M up and running.

    Then it's time to finish up the z80 ops and get the EXZ80 CPU diagnostic passing.

    I know I'm going to have a fight with flag settings again......

    There is a bunch of Z80 ops to do with interrupts that will probably never be implemented.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-03-04 19:58
    Gadgetman, if you have any CP/M rarities hiding away people would like to know.

    PDP-11 may have been easier[noparse]:)[/noparse] I have no idea, but the Z80 instruction set is total chaos. No wonder most of the instructions are not used by most software.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • GadgetmanGadgetman Posts: 2,436
    edited 2009-03-04 20:51
    I have several CP/M machines that I've added to my collection over the years, and with them there's sometimes been a few floppies...

    Off the top of my head I can mention these machines:
    Osborne One
    KayPro (HDD inside... may contain goodies... )
    Epson HX-20
    Commodore SX-64.

    Unfortunately, my collection is a complete shambles, and a lot of the stuff is packed away in crates so it's not that easy to find out exactly what I have...
    (I'm working on fixing a better arrangement in the attic, but this takes time. A lot of time... )

    And no, PDP-11 is not easy.
    The thing uses virtual memory...
    The only assembler I ever tried on it used OCTAL, and Source/destination was switched around, compared to most other CPUs.
    (I only did one assignment on it; building a simple 'OS' that could load and run a program from 8" floppies... I think they had us do work on the PDP so that we would appreciate more the more modern tools we used on other machines... )

    The reason most Z80 instructions are so little used is that many programmers began on the 8080 or 8085, and never 'upgraded' their skills or tools for the Z80. In one class I attended, we programmed the Tiki 100(CP/M-clone) which had a Z80, but the tool we used was a Borland assembler which only knew 8085, and all Z80-specific commands had to be handled as DATA, and hand-coded.
    The Z80 is incredibly efficient compared to the 8085, but only if the programmer KNOW how to use the extended command-set.
    I like to disassemble old code(ROMs from assorted computers) and have seen machines that NEVER EVER use the EXX commands, not even for interrupt handling.
    I've seen manual block moves...
    Manually built loops to do repeated IN commands...

    I have yet to see a single computer using the special interrupt mode of the Z80.
    (The mode where it waits for the interrupting device to place a Byte on the Data-bus to be combined with the Interrupt-register to form a pointer into a tale to locate the interrupt routine. This could potentially handle 128 different interrupting devices... AAAAARGH! )
    The machines where there's ANY use of the #0066H interrupt address it's usually a remnant of the debugger used during the coding stages.
    There exists a 'Power saving' version of the Z80, known as NSC800, and while it has the exact same command-set, it handles interrupts slightly differently, the DATA-bus is multiplexed with the address-bus(like on the 8085, killing a major speed-advantage) and most importantly, it has a register placed in the I/O range at address BBH.

    I found that one in a Philips Videowriter (word-processor and Printer combined into one ugly box)
    As it was localized with Norwegian menus and keyboard, I assume it was once somewhat common.
    Inside the code I found JP instructions using the IY-register, so those instructions were used by some people.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
Sign In or Register to comment.