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

ZiCog a Zilog Z80 emulator in 1 Cog

1246741

Comments

  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-03-11 22:30
    It ran!

    Yes, the ex af,af may well have been data being misinterpreted by the disassembly as code. All the more amazing that the simulation threads its way through without getting confused about data vs code, because it would only take one instruction that should be 2 bytes to be misinterpreted as 3 bytes for the whole thing to stop working.

    One minor thing - that program run looks like it is running over and over. It is supposed to end and go back to cp/m A> after one print of "Hello World".

    I'll see if I can find some more code to exercise it a bit more - eg floating point numbers and strings. Documentation is hard to come by, but there is a fairly good chance that sbasic is written entirely in 8080.

    Looking forward to the boards...
  • heaterheater Posts: 3,370
    edited 2009-03-12 05:32
    Well, I cheated a bit. I don't have a quick way to transfer files into the CP/M files system yet so I just dropped the program into the Z80 RAM space in HUB at $0100 from where it runs immediately. When it ends it does a warm boot or such and so ends up running again. All the IO goes through BDOS as normal though.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-03-12 05:57
    Ah. So do you have all of CP/M sitting at the top of the 20k code space? If so, that will be capturing input from the keyboard which I guess is from the spin terminal code. In CP/M you type the name of a file and it goes through and just tests the word is not a keyword like TYPE or DIR, then if it isn't it loads the program into 0100 and does a jump to the beginning. So you have the ability to list files with a DIR, but not quite yet the ability to load those files into 0100? I won't say that is a trivial task because the N8VEM code to do that is actually quite a slab of the whole CP/M code, plus there is different code for different drives, eg the eprom drive and the ram drive. Looking at the triblade, I guess there would be a ram drive (may as well add it) and various SD drives up to the max 8mb that CP/M uses. A generic question, my understanding is that SD cards 'wear out', a bit like eeproms wear out with lots of writes? Maybe that isn't true but I'm figuring that for files where you store the file infrequently then the SD card would be the place to put it, and for files that are used often (eg text files that a program is reading in and out) then a ramdrive would be better. Do you have access to the source code for the CP/M the SIMH uses as well as the source code for the N8VEM CP/M?
  • Mike GreenMike Green Posts: 23,101
    edited 2009-03-12 06:03
    SD memory cards have a processor inside that is supposed to do "wear levelling". There's extra space on the card that's used for keeping track of how often a section of the flash memory has been used. When a sector has been written a number of times, it's moved elsewhere in the flash memory to an area that hasn't been used and the processor keeps track of where it's been moved.
  • heaterheater Posts: 3,370
    edited 2009-03-12 07:40
    Dr_a,

    OK, my set up is a bit weird just now.
    1. There is a CP/M file system on the SD card. Actually eight of them one for each floppy disk drive.
    2. Drive A: contains all the files from the SIMH cpm2 boot disk plus a few extras I have put there. The other drives are empty but usable.
    3. However currently I do not boot up from the SD card.
    4. Instead, CPP, BDOS and BIOS are loaded into memory from files included into zicog_demo.spin. In effect the boot loader is in Spin.
    5. When CP/M is running commands are ARE indeed read from SD card e.g. DIR, loaded to 100 and executed. See previous screen shots.

    Funny you should mention TYPE and DIR. In my CP/M build (from SIMH) these commands are not built in to the CPP, DIR is read from disk, so you have to have a working disk before you can even try to see what is on it.

    Now my problem is if I want to add a new program to drive A: I have to add it to a disk image, using SIMH, and load the new disk image into the SD card. This takes ten minutes to download so I don't do it often. I have no card reader/writer so I do this via serial download to the Prop which then writes the image to the SD card. Having a card reader would not help as I use only CP/M format on the card, no FAT. This will probably change in the future.

    So to run your test I cheated and included it with the files loaded at boot time. Had I taken the time to build a new disk image with that program on it would be run as a normal CP/M command.

    All the CP/M source code (CPP, BDOS, BIOS) is included in the SIMH cpm2 disk image. Just run up the AltairZ80 simulator on your PC using the cpm2 disk. At the cp/m prompt you can write files out from the disk to your host (Windows or Linux) using the "w" command. e.g. "w cpp.mac" gets you the source of cpp. There is a "r" command to read files back into CP/M.

    I don't know what the life time of an SD card is but I'm sure that for normal "manual" usage it is longer than mine. I would only worry about it if I had a continuously running program that rapidly updates some file in which case a RAM drive would be better. To do this under ZiCog would only require a small change to he disk emulation. To do it on a normal CP/M machine would require changes to the BIOS.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-03-12 07:50
    OK here is a depressing picture.

    I just managed to get enough Z80 ops working that he Z80 CPU exerciser program (from the SIMH project) at least starts up and runs without crashing the emulator.

    As you can see all the tests FAIL.

    There is only the first few tests on the screen each of which cycles through a few tens of test cases, there are actually 80 tests many of which have tens and hundreds of thousands of test cases. Could take many hours(days) to run.

    There is a long road ahead.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
    646 x 733 - 29K
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-03-12 10:33
    I had a 200km round-trip drive to collect my pcbs late this afternoon... it's going to be a late night (photos posted on the Prop SBC thread) jumpin.gif

    Oh and heater - my laptops drop chars but I like it... iCog.

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

    · Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
    · 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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-03-12 12:47
    That is a long drive!

    @heater, I've just put those exerciser programs on a real board. They are *very* slow - I think they were designed for testing the simh which emulates a 180Mhz machine. Have you seen the source code anywhere - it could be handy to both decrease the number of tests and also narrow down exactly which instruction is failing.

    Down the track certainly a faster system is needed for running a program. I needed another N8VEM board for the wireless mesh project tonight, and it was 30 mins to solder the board, 3 mins to program an eprom (which has CP/M and xmodem on it), and then 5 mins to run a batch program to fill up a drive with about 20 files. I've got it all automated and down the track no doubt we can do the same for the triblade. 38400 baud means most CP/M files are under 30 seconds per file and some are only a few seconds.

    You might be interested to see this printout - it seems crc errors are coming up on a real board too:

    A>ex8080
    Switched to 8080 processor.
    8080 instruction exerciser
    add hl,<bc,de,hl,sp>..........( 35,840) cycles OK
    aluop a,nn....................( 45,056) cycles ERROR **** crc expected:3f92a27
    3 found:d13cf741
    aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles ...

    So maybe your simulation is ok after all??


    Attached is an sbasic program to do some maths and strings. Change the extension to a .COM as before. Code below:
    rem  Converts string to upper case
    function ucase(mystring=string) = string
        var i=integer
        var outstring=string
        var ch=byte
        outstring=""
        for i=1 to len(mystring) 
              ch=mid(mystring,i,1)
            if ch>='a' and ch<='z' then ch=ch-32    
            outstring=outstring+chr(ch)
        next i
    end=outstring
    
    
    rem ************ MAIN **************
    
        var integertest=integer
        var realtest=real
        var stringtest=string
        
        integertest=5
        integertest=integertest+10
        print "5+10=";integertest
    
        realtest=2
        realtest=realtest^.5
        print "Square root of 2:";realtest
    
        stringtest="Hello World"
        print left$(stringtest,5)
        print right$(stringtest,5)
        print ucase(stringtest)
    
    end
    
    

    Post Edited (Dr_Acula (James Moxham)) : 3/12/2009 1:01:11 PM GMT
  • heaterheater Posts: 3,370
    edited 2009-03-12 13:13
    Dr_A, You have the wrong exerciser their use EXZ80DOC.COM

    There are three versions of the exerciser, they are all built from the same source EX.MAC but with some changes made to an included file (I think the file included by EX.MAC is EC.LIB.

    So to build it copy one of ECZ80ALL.LIB, ECZ80DOC.LIB or EC8080.LIB to EC.LIB and the assemble EX.MAC

    ECZ80ALL is for testing all Z80 ops and all the flags documented or not.
    ECZ80DOC is for Z80 ignoring undocumented flags
    EC8080 is for 8080/8085.

    You have the source already I guess.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-03-12 13:17
    Oh yeah, forgot to say. The EC8080 version exists because the Z80 sets flags differently to 8080/8085.

    When I rebuilt the EXZ80DOC I reordered all the tests to put the quickest ones first.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-03-12 13:50
    Things are looking, up ZiCog is passing some Z80 CPU tests.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
    646 x 733 - 31K
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-03-12 20:08
    Z80 instruction exerciser
    Undefined status bits taken into account
    <adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles OK
    add hl,<bc,de,hl,sp>..........( 35,840) cycles OK
    add ix,<bc,de,ix,sp>..........( 35,840) cycles OK
    add iy,<bc,de,iy,sp>..........( 35,840) cycles OK
    aluop a,nn....................( 45,056) cycles OK
    aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles ERROR **** crc expected:06c7aa8e found:1b9e9b5e
    aluop a,<ixh,ixl,iyh,iyl>.....(376,832) cycles OK
    aluop a,(<ix,iy>+1)...........(229,376) cycles OK
    aluop a,(<ix,iy>-1)...........(229,376) cycles OK
    bit n,(<ix,iy>+1).............( 2,048) cycles OK
    bit n,(<ix,iy>-1).............( 2,048) cycles OK
    bit n,<b,c,d,e,h,l,(hl),a>....( 49,152) cycles OK
    cpd<r>........................( 6,144) cycles OK
    cpi<r>........................( 6,144) cycles OK
    <daa,cpl,scf,ccf>.............( 65,536) cycles ERROR **** crc expected:6d2dd213 found:2af51f3e
    <inc,dec> a...................( 3,072) cycles OK
    <inc,dec> b...................( 3,072) cycles OK
    <inc,dec> bc..................( 1,536) cycles OK
    <inc,dec> c...................( 3,072) cycles OK
    <inc,dec> d...................( 3,072) cycles OK
    <inc,dec> de..................( 1,536) cycles OK
    <inc,dec> e...................( 3,072) cycles OK
    <inc,dec> h...................( 3,072) cycles OK
    <inc,dec> hl..................( 1,536) cycles OK
    <inc,dec> ix..................( 1,536) cycles OK
    <inc,dec> iy..................( 1,536) cycles OK
    <inc,dec> l...................( 3,072) cycles OK
    <inc,dec> (hl)................( 3,072) cycles OK
    <inc,dec> sp..................( 1,536) cycles OK
    <inc,dec> (<ix,iy>+1).........( 6,144) cycles OK
    <inc,dec> (<ix,iy>-1).........( 6,144) cycles OK
    <inc,dec> ixh.................( 3,072) cycles OK
    <inc,dec> ixl.................( 3,072) cycles OK
    <inc,dec> iyh.................( 3,072) cycles OK
    <inc,dec> iyl.................( 3,072) cycles OK
    <ini,outi,ind,outd><,r>.......( 65,536) cycles ERROR **** crc expected:47fff448 found:a48a703b
    ld <bc,de>,(nnnn).............( 32) cycles OK
    ld hl,(nnnn)..................( 16) cycles OK
    ld sp,(nnnn)..................( 16) cycles OK
    ld <ix,iy>,(nnnn).............( 32) cycles OK
    ld (nnnn),<bc,de>.............( 64) cycles OK
    ld (nnnn),hl..................( 16) cycles OK
    ld (nnnn),sp..................( 16) cycles OK
    ld (nnnn),<ix,iy>.............( 64) cycles OK
    ld <bc,de,hl,sp>,nnnn.........( 64) cycles OK
    ld <ix,iy>,nnnn...............( 32) cycles OK
    ld a,<(bc),(de)>..............( 44) cycles OK
    ld <b,c,d,e,h,l,(hl),a>,nn....( 64) cycles OK
    ld (<ix,iy>+1),nn.............( 32) cycles OK
    ld (<ix,iy>-1),nn.............( 32) cycles OK
    ld <b,c,d,e>,(<ix,iy>+1)......( 512) cycles OK
    ld <b,c,d,e>,(<ix,iy>-1)......( 512) cycles OK
    ld <h,l>,(<ix,iy>+1)..........( 256) cycles OK
    ld <h,l>,(<ix,iy>-1)..........( 256) cycles OK
    ld a,(<ix,iy>+1)..............( 128) cycles OK
    ld a,(<ix,iy>-1)..............( 128) cycles OK
    ld <ixh,ixl,iyh,iyl>,nn.......( 32) cycles OK
    ld <bcdehla>,<bcdehla>........( 3,456) cycles OK
    ld <bcdexya>,<bcdexya>........( 6,912) cycles OK
    ld a,(nnnn) / ld (nnnn),a.....( 44) cycles OK
    ldd<r> (1)....................( 44) cycles OK
    ldd<r> (2)....................( 44) cycles OK
    ldi<r> (1)....................( 44) cycles OK
    ldi<r> (2)....................( 44) cycles OK
    neg...........................( 16,384) cycles OK
    <rrd,rld>.....................( 7,168) cycles OK
    <rlca,rrca,rla,rra>...........( 6,144) cycles OK
    shf/rot (<ix,iy>+1)...........( 416) cycles OK
    shf/rot (<ix,iy>-1)...........( 416) cycles OK
    shf/rot <b,c,d,e,h,l,(hl),a>..( 6,784) cycles OK
    <set,res> n,<bcdehl(hl)a>.....( 6,912) cycles OK
    <set,res> n,(<ix,iy>+1).......( 448) cycles OK
    <set,res> n,(<ix,iy>-1).......( 448) cycles OK
    ld (<ix,iy>+1),<b,c,d,e>......( 1,024) cycles OK
    ld (<ix,iy>-1),<b,c,d,e>......( 1,024) cycles OK
    ld (<ix,iy>+1),<h,l>..........( 256) cycles OK
    ld (<ix,iy>-1),<h,l>..........( 256) cycles OK
    ld (<ix,iy>+1),a..............( 64) cycles OK
    ld (<ix,iy>-1),a..............( 64) cycles OK
    ld (<bc,de>),a................( 96) cycles OK
    Some failure detected.
    CP/M V2.2C
    A>
  • heaterheater Posts: 3,370
    edited 2009-03-12 20:38
    Dr_A,

    You know, I had already been wondering.... In the source code of the EX test Frank Cringle states that the CRCs resulting from the tests are compared to CRC's he got running the same test on a real MOSTEK Z80. So I was wondering if a real original Zilog Z80 would be in any way different.

    Looks like with the daa and alu op tests above that you may have found some differences. Are you running a Zilog chip?

    Of course the third failure you have there concerns IN operations, well how can that be expected to pass except of the machine Frank used to create the CRC's

    Anyway, if you are using a real Zilog Z80 I would like to use your CRC results in my tests. For authenticities sake, after all this is ZiCog not MoCog. Trouble is we now need to find out why they are different.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-03-12 23:57
    Hmm, a real Zilog chip?

    I'll double check when I get home from work. The only spanner in the works is that about 10 years ago I spent a king's ransom buying a number of Z80 chips from Radio Spares. They were very expensive, they were rated at 8Mhz and they were CMOS. These chips run cold.

    Now, in the last year, I have a parts drawer full of about 20 new Z80 chips that I have bought from all over the world. Most are labelled Zilog. Some are 4Mhz, some are 6 and some are 8. All are supposed to be cmos. Some have identical part numbers to the chips from Radio Spares. But every single one runs warm.

    I cannot seem to find a single new Z80 chip that will run cold, and what I am wondering is whether there are fake chips out there, and people just print "Zilog" on the chip and no-one cares.

    What I can say though is that they all seem to run the software ok. That could be because none of the code I'm using actually uses DAA or depends on unusual flag configurations (the Zero flag is the one used most of the time).

    I guess what we need is to get inside the exerciser program and see how it works.

    Good news that you have got so many instructions working!

    Addit: scratch that bit about the source code, I just found your post on the .mac files. The doc one is for undocumented instructions? I was guessing it was the documentation for the program. Ok, with the .mac file we can go to work and narrow down just the exercises that are failing. It will speed things up a bit too - that program run took more than half an hour.

    Post Edited (Dr_Acula (James Moxham)) : 3/13/2009 12:07:48 AM GMT
  • heaterheater Posts: 3,370
    edited 2009-03-13 06:55
    I don't know about fake chips. There were/are many companies making Z80 clones. I read somewhere that half the Z80's in the world were not made by Zilog. Perhaps all these clones had their subtle differences. And perhaps someone has been relabelling clones as Zilogs.

    Of course Zilog still exists and according to their web site we could get hold of new Z80 samples to try out !

    No. The "DOC" version of EX is for testing the documented flag settings, the "ALL" also checks the undocumented flags. I made the same mistake as you thinking that DOC meant the program documentation.

    However, some strange things, it is possible to access IX and IY as two pairs of 8 bit registers IXH, IXL, IYH and IYL. Much like H and L. Well this is an undocumented feature of the Z80 but there are tests for it in the "DOC" version. Of course ZiCog does not support this yet.

    Did you know that the Z80 uses 16 bit addresses (from BC) for it's I/O instructions? Turns out the Sinclair ZX81 used this. Might have know Clive Sinclair was always using "odd" features of devices.

    The EX program is very clever at what it does. Checking that millions of instruction/data combinations have the same result as a real chip. But it does make it hard to pin down exactly which instruction, flag whatever maybe causing a problem. Still it can be done by narrowing down the number of test cases generated, running the code on two different machines, Zilog and emulation say, and comparing the CRCs. You do have to have a reference machine to do this.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-03-13 07:31
    Dr_A,

    OK here is what you could do with EX to find the difference between your "real" Zilog chip and the SIMH. Or I might do to track down hard problems in ZiCog:

    1. Rebuild the EX test with the trace option set, see EX.MAC. This will print out the machine state, registers and a few bytes of memory, together with the current CRC value after EVERY test combination.

    2. Comment out all tests in the tests list except one that you are interested in.

    3.Run this modified EX on the real Z80 and SIMH. This will take a long while as output is through serial console port.

    4.Capture the output to files.

    5. Use diff (linx) or WinDiff to find where the results differ. There we will see exactly the instruction and test data that produces a different result.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-03-14 10:28
    Re 1) I'm not having much luck rebuilding ex.mac. I've changed the settings at startup but I'm getting fatal errors with M80. I think it might be this line MACLIB EXCONFIG.LIB because I can't find that file. Do you have a copy by any chance?
  • heaterheater Posts: 3,370
    edited 2009-03-15 06:59
    I bet you already have what you need. Just use ECZ80DOC.LIB

    PIP EXCONFIG.LIB=ECZ80DOC.LIB

    Actually what I did was to remove the use of that file all together and put the equates in EX.MAC and renamed it ZICOGTST.MAC

    When assembling this on a SIMH cpm2 disk it fails with DISK FULL so I had to make more room.

    Attached shows ZiCog is making some progress on passing those tests. All loads and stores, but at least the addressing modes are working nicely.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
    646 x 733 - 27K
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-03-15 18:38
    My TriBladeProp is running with SRAM so it's time to start with ZiCog smile.gif

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

    · Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
    · 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-16 07:46
    Attached is v0.4 of zicog.

    This version is set up to run a version of the SIMH AltairZ80 CPU diagnostic with output to PropTerminal. No SD card required here.

    With a one line change (move a comment tick) in zicog_demo.spin (look for "OPTIONS" it will run a 20K CP/M up to the command prompt. With a CP/M file system on SD card CP/M commands, DIR etc, will work as well.

    I have modified the SIMH diagnostic (and called it zicogtst.com) so as to exclude tests of undocumented instructions. It also performs tests in order of their execution time as the alu ops take forever.

    The old T8080.COM cpu diagnostic is gone as it no longer passes now that we are implementing Z80 flag settings not 8080.

    The zicogtst has a lot of failures still but results show that all Z80 addressing modes are handled correctly and all the increment/decrement instructions work. See attached screen shots.

    Work continues on getting all the tests to pass but I'm getting a bit stuck with only 4 longs left in the COG. Moving the A reg back to HUB will free up some space as will getting rid of the "ROM" memory access function when Cluso has the external RAM working. There is not a lot left I can put into overlays.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
    646 x 733 - 26K
    646 x 733 - 32K
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-03-17 11:53
    Heater:

    I am just about to start·have started testing ZiCog v0.4 and I have a few questions.

    I have changed the xtal to 5MHz and pll16.

    I have uncommented the first instruction in options and it now works (Note there are 3 instructions not 2 and need to enable only 1) - currently run on Blade#3·so no SRAM conflicts.

    What I/O pins do you use and where? The heartbeat/frequency counter uses one - I have to remove all so they do not conflict with the SRAM - will have to think about how we can get an indication back and use the LED (maybe we can connect the LED to one of the address pins to see it toggling)

    I will have to copy the hub ram (the Z80 RAM) to the SRAM. I will just do this in spin - slow but easy - and I can do this before the Z80 cog is started.

    Anything else you can think of ???

    I notice you use PropTerminal. I haven't used this - I usually use PST, but expect PropTerminal will be required. Do you know if this releases the com port when it loses focus (like PST)? I will look this up. Found and answered. My test code sees mouse movements.

    I note the Ram size in hub is only $4F00. Shouldn't this be $5000 ??

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

    · Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
    · 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

    Post Edited (Cluso99) : 3/17/2009 1:26:40 PM GMT
  • heaterheater Posts: 3,370
    edited 2009-03-17 14:53
    Clusso:

    OK, you want to be brave and go straight to running CP/M from external RAM [noparse]:)[/noparse]

    I assume you have written the external RAM access PASM routines, tested them somehow, and fitted them into zicog.spin.
    I assume you have had a CP/M sign on message and prompt coming out on PropTerminal. That's as far as we get with out an SD card but good for now.

    1. Uncomment the first option line only (yes the first one of three) in zicog_demo. As you have done.

    2. Add something to zicog_demo to zero all your RAM first. The reason for this will be seen in a later experiment.

    3. Add something to zicog_demo to copy the HUB RAM from ram_z80 length 20K into the external RAM at $0000
    There should not be any need to worry about the addresses of CCP, BDOS etc at this stage as this RAM image should work the same from HUB or external.

    4. Add something to zicog_demo to copy the HUB RAM from rom_z80 length $0100 (256) into external RAM at $FF00.
    This is the bootstrap EEPROM image. It is not used for boot strapping here but at least one byte of it is accessed by the BIOS to determine which floppy disk to boot from. Things dont go well with out it.

    It should just work now[noparse]:)[/noparse]

    If not try this test:

    1. Uncomment the two lines in zicog.spin that cause a break in execution after every instruction.
                            mov     OVERLAY_PAR, break_ovl_    '\\ copy break_ovl's parameters                                 
                            call    #OVERLAY_LOAD              '// load & execute break_ovl                  
    
    


    2. Run again.
    3. Hitting a key should cause zicog to step on instruction as the attached image shows. First instruction at PC=0000 is jump (C3) to $4200. Second instruction at $4200 is jump (C3) to $4233 etc etc.



    As for IO pins:
    The heartbeat, can be removed for now.
    The SD card pins. Can be removed. You should still get a CP/M prompt even if SD access fails.
    The Prop loader pins as used by Propterminal.

    Never noticed before but the RAM size is 256 bytes short. That's because in a 64K system the top 256 bytes are the bootstrap EPROM.

    If you have any problems contact me by email. Save cluttering up the thread.

    Good luck.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
    646 x 733 - 30K
  • WNedWNed Posts: 157
    edited 2009-03-17 22:03
    Clutter the thread! Clutter the thread!
    I first learned ASM on a TRS-80 Model I... Forgot it all loooong ago, but love reading everything about the progress of this project!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "They may have computers, and other weapons of mass destruction." - Janet Reno
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-03-18 02:32
    Update:
    I have heaters code working on Blade #3 (no SRAM, so the heartbeat doesn't interfere with the SRAM)
    Modified the code to remove the heartbeat and SD card interface (so no I/O pins are used) and running on Blade #2 (with SRAM)
    Added copying and verifying the z80 ram/rom to the SRAM

    Next: I am in the middle of modifying the code to run from SRAM. It will be a full 64KB version. Expect to complete this tonight my time. smile.gif

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

    · Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
    · 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-18 06:25
    For WNed here is some clutter.

    Attached is zicog v0.5.

    Cluso needs some free LONGs in which to implement external RAM access on the TriBlade so:

    1. The z80 A register has been moved back into HUB space. This slows everything by 1% or so but saves many LONGs.
    2. The NEG instruction emulation is moved into an overlay.

    Getting z80 accurate flag settings has been eating up the COG but I think we are nearly there.

    In this version all alu ops (add, sub, or, xor etc) are passing the EXZ80DOC test. As are NEG and double adds (DAD B etc)


    Cluso, In this version there are 13 free LONGs. Things are getting tight but pretty much everything I need to fix now will happen in the overlays where all the z80 stuff lives. I'm sure we can find another handful of longs if we really have to.

    Do not try to use the CP/M files included in Zicog (or PropAltair) to create a 64K CP/M system they will not work. When the 20K version is running we will work on that.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
    646 x 733 - 30K
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-03-18 09:43
    Thanks heater. Today before I had to go out, I had the code loading into SRAM and single-stepping (SRAM write disabled) but it is failing because it is reading from 0000=C3, then 0001=00 (shoud be 4200=C3. Haven't had time to look, but could be where option may change what is in the ram after I have already loaded the sram - will check shortly. Hadn't disabled output on the cog after loading sram. Still error though 0000=C3, 0003=00, 0005=c3.

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

    · Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
    · 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

    Post Edited (Cluso99) : 3/18/2009 10:01:04 AM GMT
  • heaterheater Posts: 3,370
    edited 2009-03-18 10:04
    Hmm, C3 is correct as the first byte. Not sure I follow, nothing should be changing that z80 RAM area in HUB except the CPU emulator itself.

    Suggest putting something in zicog_demo.spin to read and print out the first few bytes of ext RAM after it is loaded but before starting the CPU.

    You should see from address zero up:

    C3, 00, 42, 00, 00, C3, 00, 34, 00, 00, 00.......

    It's all zeros up until address 0100 where we get the zicogtst code:

    C3, 65, 01......

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-03-18 10:27
    OK - bug found (loading/verifying to one sram, then trying to read the code from the other sram) :-(
    Now implementing wih v0.5 - standy...

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

    · Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
    · 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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-03-18 11:43
    This is a bit sad to admit but I confess to being able to read these numbers as instructions. C3 is jump. Then the next two bytes are the LSB and then MSB. So it will be C3 00 42 which is a jump to 4200 which is lower than the usual sorts of numbers which are up near the top of 64k of ram. Cluso99 - good to hear payment went thru and I'm looking forward to a board.
  • heaterheater Posts: 3,370
    edited 2009-03-18 11:57
    "C3 00 42"

    Yep, gets to you after a while.

    We are starting off with a known working CP/M build in 20K, so the address is a bit low, when that flies we'll go the Full Monty.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
Sign In or Register to comment.