@heater - making lots of progress. Have put many messages through the spin code and single stepping it through. Runs ziboot then stepping through this code and got to
FF4E DB FD in a,(hdskport) ; perform operation and get result
FF50 B7 or a
FF51 CA FF55 jp z,cont1 ; continue if no error
FF54 76 halt ; halt otherwise
FF55 79 cont1: ld a,c ; save loop counter in <A>
The in a(hdskport) gets trapped by the spin code and reads a sector off the sd card and writes it to memory location $0000 This appears to be:
000 C3
0001 00
0002 01
0003 E5
0004 E5
and then E5 for all the rest
Which I think is a jmp $0100
But then it seems to fall apart at FF50 with the "or a"
Single stepping gives this:
...
007E E5
007F E5
Write finished
128 bytes written to memory
PC=FF50 AF=0044 BC=0058 DE=0008 HL=0000 IX=0000 IY=0000 SP=0000
Spacebar for next instruction
PC=FF51 AF=0044 BC=0058 DE=0008 HL=0000 IX=0000 IY=0000 SP=FFFE
Spacebar for next instruction
PC=FF52 AF=0044 BC=0058 DE=0008 HL=0000 IX=0000 IY=0000 SP=FFFC
Spacebar for next instruction
The SP is decrementing and it neither does a halt nor a jump.
What does the "or a" do, and can one guess from the F register of 44 whether Z is set or not?
1) Prior to the "in a,(hdskport) " there is a bunch of OUT instructions to the hdskport setting up a read command with disk, sector, track and DMA address parameters.
2) The " in a,(hdskport) " then triggers the actual disk read command. So at this point emulation should pause while the disk sector is DMAed to the buffer at DMA address and then a success/fail result returned in the A register.
3) A return value of zero in the A register means "success" but the IN instruction does not set the Z flag. So "or a" is used to set the Z flag from the content of the A reg. One might think to use a compare with zero here "cp 0" but that is two bytes instead of one. Programmers used to think about such things.
4) It seems in your case the disk read has returned with A = 0 which and F = 44H after the OR instruction which is indicating ZERO (in bit 6) and PARITY (in bit 2).
5) At PC=FF51 things are going bad because the jump is not taken when it should be and we end up at PC=FF52 which really should not happen as it is in the middle of a three byte instruction.
Why this is going wrong I can't say. I'll try to think about it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks heater. That gives me quite a few things to experiment with.
When it does an 'in' from the hard drive, does that pause execution of the zicog in some way until the spin code has transferred all the bytes over? How does that part work?
So the PASM execution hangs in these loops until the output byte is handled or the input byte is available. That is until the hardware emulation in zicog_cpm.spin sets the io_command back to zero.
So in zicog_cpm.spin you will find "io_command := 0" at the end of the on_input and on_output methods.
In this way either the PASM emulation is executing or the Spin hardware emulation is executing. Never both at the same time.
So yes for hard disk reads the block transfer is triggered by IN from the hdskport which will hang up the PASM until the Spin has fetched the required block and written it to the DMA buffer. At which point io_command is set back to zero causing the IN emulation to exit the wait loop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Am still working through some code - I've got two bugs to squish - one is that the first record off drive 0 does not seem to be correct. And second it still having trouble with the low level ram access.
Can I ask - in which file does CP/M reside on the sd card and which bit of code loads this?
Stuck at the moment - memory getting corrupted. Narrowed it down in a single step routine to the PRI on_break - if add just one memory read to a random location after the printout of the registers, the whole zicog falls over. Ditto a write, but the fact it does it just after a read is kind of suggesting there is a clash somewhere and the zicog is still trying to access the memory too. No problems with all sorts of memory read/writes before the zicog cog is started.
How about HDCPM2_A.DSK, aka ZIPM2.DSK, the 8MB CP/M 2 boot disk. Assuming you are not wanting to boot from a floppy image.
Not sure I understand "which bit of code loads this?". CP/M is on the boot sectors of that disk and is loaded by the boot loader ZIBOOT.COM that you have been stepping through.
ZIBOOT loads the boot sectors to 0000H in RAM and jumps to 0. From there should be a jump to 100H, if I remember correctly, where the is a little code to move the CP/M stuff to the right places in high memory. Look at MOVER.MAC in altairz80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater Have I too simplistic thinking about how the 64KB ram load happens and is the invoked. I think you load the whole of the 64K above page zero with nops until the rom bits are run into, and kick in. I want to load 4KB, to start with, and the probably all 64K as a system image (Nascom)
It would kick off at 0000. I will have to translate the I/O stuff to talk serial and put the "Nascom" into X-xx mode (prob X20) tor terminal mode
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
0000-07FF 2K monitor rom
0800-0BFF Video ram (character mapped)
0C00-0FFF Ram (some used by monitor, some used by SP, some left for the user!! )
I/O port 0 for KBD
1 and 2 for UART data/status
This made up the bare minimum for the N1 everything else was extra. Not bad for a month's salary.
So yes there is rom at 0000 to kick strait into monitor, N2s did put a restart vector on so that at 4KB boundries restarts could be altered, but the rom addr stayed put at 0000. I can't remember if the later Nas-Sys monitors were written relocatable or not, it was the Holy Grail of coding back then.
I suppose I could be perverse and try to write a CP/M program that emulates a Nascom, to run on an emulator ....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Be aware that ZiCog is still missing a number of Z80 ops. EX, EXX, anything to do with block comparisons and such. No idea if NASCOM used these. Do you have any monitor listings to look at and check for these. In theory ZiCog will stop and dump registers if it finds an op it does not recognize so you will find out eventually.
Problem is we have precious little COG space left in which to implement any more ops even after our heavy use of overlays.
"I suppose I could be perverse and try to write a CP/M program that emulates a Nascom, to run on an emulator ...."
No don't do that, we are all quite perverse enough already wanting to run Z80 codes in 2009 [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Success! The single prop zicog with keyboard and vga is now running:
SD started
SD mounted
A:ZIPM2_6b.DSK 852817 515595148
B:ZICOG_A2.DSK 639825 515595148
C:DRAC2_64.DSK 279185 515595148
D:ZICOG_SC.DSK 803665 515595148
E:ZICOG_E2.DSK 721745 515595148
F:ZICOG_F0.DSK 738129 515595148
G:ZICOG_G0.DSK 770897 515595148
H:ZICOG_H0.DSK 787281 515595148
R:BOOTHDSK.32M <-bootcode 115281 515595148
Loading SRAM...
Skip filling memory with zero
Ram test, should print out C3 00 FF = first 3 ram bytes: C3 00 FF
Read boot code from SD card and store at $FF00
Boot code loaded
Starting 8080 emulation...
Passed, please wait...
64K CP/M Version 2.2 (ZiCog, BIOS V1.27_Zi04, 8 HD, 10-Sep-2009)
A>b:
B>mbasic
BASIC-80 Rev. 5.21
[noparse][[/noparse]CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
32824 Bytes free
Ok
10 for a=1 to 1000:next
20 print "done"
run
done
Ok
The BIG unknown with all this is how fast it would run with the need to latch address bytes in seperately to the ram. I've done a speed test and compared with a real N8VEM I'm guessing this emulates at about 2.5Mhz. An acceptable speed compromise IMHO. Especially when off-board compilation and development can be done using the N8VEM tools that shell out to the SIMH.
The part that is much slower is the disk block transfers. In order to get the debugging working I took cluso's ramblade driver and rewrote it for this board and did it all in Spin. Much easier to trace through the execution when the spin code is in the Main object. But now that this works, and now I also have a zicog pasm driver I can copy that code into a new driver in a similar way to cluso's driver.
And the bit that has had me stumped for the last week? Well, I still don't know exactly but I think it is due to two things trying to access a pin at the same time. I think fsrw alters the pins in between the lowest and highest pin numbers. So the secret was to tristate all pins after every memory read and write - both in spin and pasm. This way, if the fsrw wants to do its thing at the very least the gate on the 138 will be tristate (pulled high with 10k) and so the ram is protected. Maybe it wasn't fsrw though, because without the tristate in pasm at the end of a read, the memory got wiped before it even got to the stage of single stepping the first instruction.
Next challenge - trying to recover about 13 bytes out of the zicog in order to get Z80 opcodes working.
All good fun! And a big thanks to Cluso and Heater for all their help over the last few weeks.
Dr_A. Wow, that is truly fantastic. Looking forward to seeing a screen shot of Wordstar running on a single Prop computer.
Looking at your board I wonder how you managed to route from Prop to RAM all the way across the board. I would have been tempted to put all the chips on one side and all power supply, SD card and I/O on the other. Still if it works it works.
Not sure where we are going to get the extra space from in the COG. As you may have noticed I've been playing with the idea of splitting code over multiple COGs again for the 6809 emulator instead of using overlays. Not sure I've got the heart or tenacity to rewrite ZiCog yet again though.
How many COGs will your board end up using ? Perhaps we could move the biggest overlays out to another COG thus shrinking the required overlay area size. That would be DAA for starters. Makes for a rather messy implementation though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just looked thru the hex of Nas-Sys3 and it does have EX AF,AF' dotted all over it. Could be a cue to learn how you added bits in. ( or get my finger out and get a real Z80 going )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
If It is only instruction them use "EX AF,AF'" ..... It is only rapid substitution of --- Push, Pop AF to and from Stack
And You can reedit code ... Most posible You ned have one RAM Variable to spare AF as it can span over more that one RETURN from stack
Like.
Push A
MOV A,AF
MOV MemVar,A
Pop A
As You see that saved in Z80 many opcodes and External MEM operations
Regards
ChJ
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Yes i could do that but some of them are closly packed into the restarts locations so I would have to vector out into clear space recode and then dive back in. I am still thinking about getting brave and mimicing/adding to the overlay tricks. All part of the education.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
If them are used in RESTART/INT Vector place's ....Them are direct Replacements for ..... PUSH and POP AF on stack with no ned for Spare them as Variables to later use.
Regards.
ChJ
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
What are you running this on Toby?. On Triblade there were only 6 LONGs left! As a small system on a demo board with Z80 RAM in HUB there was a tiny bit more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
DemoBoard to start with then TriBlade if it ever gets to run. To make things even more doubtful I have just spotted a EX SP,(HL) and that is even used in the original Nasbug T2 monitor. It will be a lot easier to settle with your CP/M, and there is a whole bunch more of progs available.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Thats lucky then. I got all disappointed and had a route about in the garage. From long ago I have the front control board from a Panasonic DVC 640 machine. It has got a Z180, 32K EPROM, 32K RAM and a 8255 type. Perhaps I won't have to use it after all.
The telling thing is ... This old panel has got far more grunt to it than the Nascom ever did, and it's place in life was to just wait for a button push.
I was also thinking that with a rewrite of the monitor There should be room for the Triblade Nascom as the VDU memory will not be used so the monitor could creep up, but would have to be write protected. It would stop any games, which might not be a bad thing, BUT ... I may as well use the CP/M progs which you have already sussed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
As Ray noted a few msgs back, I just got my triblade and look forward to getting it assembled and running CP/M. Glad to see some familiar handles here as well. James, do you ever sleep?
I started computing in the early '70s, running RT-11 on a PDP/11 as a grad student and shortly thereafter moved to CP/M 2.2 on a Cromemco Z2. Gave up my thesis work for blinking lights and never looked back. Today, I'm IS Director for a small private college in Chicago and still messing around with 8-bit machines to relax after days spent running virtual W2K8. Lots of S100 stuff kicking around the basement/garage/attic and a growing pile of 6502 (Apple/Atari)·boxes as well. Moving slightly upstream, DEC PDP/8's still have a strong hold on me too, with some real iron and a couple emulators.
It's been way too many years since I even hacked a BIOS or modified MODEM7 for new hardware, to say nothing of doing serious coding, so I will mostly be watching slack-jawed as you guys continue to grow·this project from bare metal.
@jackrubin - re sleep, I am doctor acula *grin*, I prefer to work all night...
@ Toby Dr_A "Will that design be coming out to play, or is a comertial venture ?", It is all open source. There is the schematic posted on this thread a week or two ago, though it has changed slightly as it evolved. And it may change again - eg I built it for vga, but I got a 4" TV screen the other day so I'd like to try TV as well. Cluso (very wisely!) put both options on the triblade. I've got another board being made that has all the mods on it and I'll probably have a few spare.
Still some code changes to make. Ideally I'd like to have a drop in object that does the driving for this particular board and then a single ifdef at the beginning of the code that selects the triblade or the dracblade. Then all the software options can move forward as one single piece of code.
Toby: A friend of mine in New Zealand has re-bought a few Nascoms and he has a prop proto which I helped him interface to a Motorola D2 - replaces the keyboard and 7 seg display board with a prop with either keyboard + VGA or PC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
heater: I was just looking at the ZiCog code and there are a few places that some instructions could be shaved.
'Increment pc before fetching next instruction
inc_pc2_fetch add pc, #1 '<-- takes an extra instruction but saves a long
inc_pc1_fetch add pc, #1 '<-- saves a long
'Instruction fetch loop starts here
disable_interrupts
enable_interrupts
fetch
There are a few other places that could·save a jump by reorganising code.
Need to get back to a Release version 1.0 first !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The last time I saw a Nascom2 for sale, was about a year ago. It was in Holland and cost 300 euros +++. I then realized that all the old stuff I didn't have anymore would be worth a fortune.
Where is that cat ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Comments
The in a(hdskport) gets trapped by the spin code and reads a sector off the sd card and writes it to memory location $0000 This appears to be:
Which I think is a jmp $0100
But then it seems to fall apart at FF50 with the "or a"
Single stepping gives this:
The SP is decrementing and it neither does a halt nor a jump.
What does the "or a" do, and can one guess from the F register of 44 whether Z is set or not?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/14/2009 1:21:46 AM GMT
1) Prior to the "in a,(hdskport) " there is a bunch of OUT instructions to the hdskport setting up a read command with disk, sector, track and DMA address parameters.
2) The " in a,(hdskport) " then triggers the actual disk read command. So at this point emulation should pause while the disk sector is DMAed to the buffer at DMA address and then a success/fail result returned in the A register.
3) A return value of zero in the A register means "success" but the IN instruction does not set the Z flag. So "or a" is used to set the Z flag from the content of the A reg. One might think to use a compare with zero here "cp 0" but that is two bytes instead of one. Programmers used to think about such things.
4) It seems in your case the disk read has returned with A = 0 which and F = 44H after the OR instruction which is indicating ZERO (in bit 6) and PARITY (in bit 2).
5) At PC=FF51 things are going bad because the jump is not taken when it should be and we end up at PC=FF52 which really should not happen as it is in the middle of a three byte instruction.
Why this is going wrong I can't say. I'll try to think about it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
When it does an 'in' from the hard drive, does that pause execution of the zicog in some way until the spin code has transferred all the bytes over? How does that part work?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
:wait rdbyte data_8, io_command wz if_nz jmp #:waitSo the PASM execution hangs in these loops until the output byte is handled or the input byte is available. That is until the hardware emulation in zicog_cpm.spin sets the io_command back to zero.
So in zicog_cpm.spin you will find "io_command := 0" at the end of the on_input and on_output methods.
In this way either the PASM emulation is executing or the Spin hardware emulation is executing. Never both at the same time.
So yes for hard disk reads the block transfer is triggered by IN from the hdskport which will hang up the PASM until the Spin has fetched the required block and written it to the DMA buffer. At which point io_command is set back to zero causing the IN emulation to exit the wait loop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Am still working through some code - I've got two bugs to squish - one is that the first record off drive 0 does not seem to be correct. And second it still having trouble with the low level ram access.
Can I ask - in which file does CP/M reside on the sd card and which bit of code loads this?
Stuck at the moment - memory getting corrupted. Narrowed it down in a single step routine to the PRI on_break - if add just one memory read to a random location after the printout of the registers, the whole zicog falls over. Ditto a write, but the fact it does it just after a read is kind of suggesting there is a clash somewhere and the zicog is still trying to access the memory too. No problems with all sorts of memory read/writes before the zicog cog is started.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/14/2009 2:05:47 PM GMT
Not sure I understand "which bit of code loads this?". CP/M is on the boot sectors of that disk and is loaded by the boot loader ZIBOOT.COM that you have been stepping through.
ZIBOOT loads the boot sectors to 0000H in RAM and jumps to 0. From there should be a jump to 100H, if I remember correctly, where the is a little code to move the CP/M stuff to the right places in high memory. Look at MOVER.MAC in altairz80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Welcome to Jack - he has just received his TriBlade and wants to get CPM running
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Heater Have I too simplistic thinking about how the 64KB ram load happens and is the invoked. I think you load the whole of the 64K above page zero with nops until the rom bits are run into, and kick in. I want to load 4KB, to start with, and the probably all 64K as a system image (Nascom)
It would kick off at 0000. I will have to translate the I/O stuff to talk serial and put the "Nascom" into X-xx mode (prob X20) tor terminal mode
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Thing is a Z80 starts execution at 0000 after reset but computers like to have RAM at 0000 and any PROM in high memory. In CP/M for example.
So in real hardware there used to be some memory switching that would have ROM at 0000 on start up but then switch it to RAM after that.
In ZiCog we don't bother, just fill RAM with Zero (NOP) and let it run up to the ROM at FF00.
So just put what ever you want in RAM and run it.
Did a NASCOM use such hardware RAM/ROM switching ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
0000-07FF 2K monitor rom
0800-0BFF Video ram (character mapped)
0C00-0FFF Ram (some used by monitor, some used by SP, some left for the user!! )
I/O port 0 for KBD
1 and 2 for UART data/status
This made up the bare minimum for the N1 everything else was extra. Not bad for a month's salary.
So yes there is rom at 0000 to kick strait into monitor, N2s did put a restart vector on so that at 4KB boundries restarts could be altered, but the rom addr stayed put at 0000. I can't remember if the later Nas-Sys monitors were written relocatable or not, it was the Holy Grail of coding back then.
I suppose I could be perverse and try to write a CP/M program that emulates a Nascom, to run on an emulator ....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Be aware that ZiCog is still missing a number of Z80 ops. EX, EXX, anything to do with block comparisons and such. No idea if NASCOM used these. Do you have any monitor listings to look at and check for these. In theory ZiCog will stop and dump registers if it finds an op it does not recognize so you will find out eventually.
Problem is we have precious little COG space left in which to implement any more ops even after our heavy use of overlays.
"I suppose I could be perverse and try to write a CP/M program that emulates a Nascom, to run on an emulator ...."
No don't do that, we are all quite perverse enough already wanting to run Z80 codes in 2009 [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The BIG unknown with all this is how fast it would run with the need to latch address bytes in seperately to the ram. I've done a speed test and compared with a real N8VEM I'm guessing this emulates at about 2.5Mhz. An acceptable speed compromise IMHO. Especially when off-board compilation and development can be done using the N8VEM tools that shell out to the SIMH.
The part that is much slower is the disk block transfers. In order to get the debugging working I took cluso's ramblade driver and rewrote it for this board and did it all in Spin. Much easier to trace through the execution when the spin code is in the Main object. But now that this works, and now I also have a zicog pasm driver I can copy that code into a new driver in a similar way to cluso's driver.
And the bit that has had me stumped for the last week? Well, I still don't know exactly but I think it is due to two things trying to access a pin at the same time. I think fsrw alters the pins in between the lowest and highest pin numbers. So the secret was to tristate all pins after every memory read and write - both in spin and pasm. This way, if the fsrw wants to do its thing at the very least the gate on the 138 will be tristate (pulled high with 10k) and so the ram is protected. Maybe it wasn't fsrw though, because without the tristate in pasm at the end of a read, the memory got wiped before it even got to the stage of single stepping the first instruction.
Next challenge - trying to recover about 13 bytes out of the zicog in order to get Z80 opcodes working.
All good fun! And a big thanks to Cluso and Heater for all their help over the last few weeks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/15/2009 12:34:51 PM GMT
I suppose the next version will be one prop less !
Heater
I don't recall any useage of EX ... etc Block transfers gallore but not compares ( but it was 30 years ago )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 11/15/2009 12:37:17 PM GMT
Looking at your board I wonder how you managed to route from Prop to RAM all the way across the board. I would have been tempted to put all the chips on one side and all power supply, SD card and I/O on the other. Still if it works it works.
Not sure where we are going to get the extra space from in the COG. As you may have noticed I've been playing with the idea of splitting code over multiple COGs again for the 6809 emulator instead of using overlays. Not sure I've got the heart or tenacity to rewrite ZiCog yet again though.
How many COGs will your board end up using ? Perhaps we could move the biggest overlays out to another COG thus shrinking the required overlay area size. That would be DAA for starters. Makes for a rather messy implementation though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Will that design be coming out to play, or is a comertial venture ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Just looked thru the hex of Nas-Sys3 and it does have EX AF,AF' dotted all over it. Could be a cue to learn how you added bits in. ( or get my finger out and get a real Z80 going )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
If It is only instruction them use "EX AF,AF'" ..... It is only rapid substitution of --- Push, Pop AF to and from Stack
And You can reedit code ... Most posible You ned have one RAM Variable to spare AF as it can span over more that one RETURN from stack
Like.
Push A
MOV A,AF
MOV MemVar,A
Pop A
As You see that saved in Z80 many opcodes and External MEM operations
Regards
ChJ
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Yes i could do that but some of them are closly packed into the restarts locations so I would have to vector out into clear space recode and then dive back in. I am still thinking about getting brave and mimicing/adding to the overlay tricks. All part of the education.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
If them are used in RESTART/INT Vector place's ....Them are direct Replacements for ..... PUSH and POP AF on stack with no ned for Spare them as Variables to later use.
Regards.
ChJ
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
DemoBoard to start with then TriBlade if it ever gets to run. To make things even more doubtful I have just spotted a EX SP,(HL) and that is even used in the original Nasbug T2 monitor. It will be a lot easier to settle with your CP/M, and there is a whole bunch more of progs available.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
The telling thing is ... This old panel has got far more grunt to it than the Nascom ever did, and it's place in life was to just wait for a button push.
I was also thinking that with a rewrite of the monitor There should be room for the Triblade Nascom as the VDU memory will not be used so the monitor could creep up, but would have to be write protected. It would stop any games, which might not be a bad thing, BUT ... I may as well use the CP/M progs which you have already sussed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
As Ray noted a few msgs back, I just got my triblade and look forward to getting it assembled and running CP/M. Glad to see some familiar handles here as well. James, do you ever sleep?
I started computing in the early '70s, running RT-11 on a PDP/11 as a grad student and shortly thereafter moved to CP/M 2.2 on a Cromemco Z2. Gave up my thesis work for blinking lights and never looked back. Today, I'm IS Director for a small private college in Chicago and still messing around with 8-bit machines to relax after days spent running virtual W2K8. Lots of S100 stuff kicking around the basement/garage/attic and a growing pile of 6502 (Apple/Atari)·boxes as well. Moving slightly upstream, DEC PDP/8's still have a strong hold on me too, with some real iron and a couple emulators.
It's been way too many years since I even hacked a BIOS or modified MODEM7 for new hardware, to say nothing of doing serious coding, so I will mostly be watching slack-jawed as you guys continue to grow·this project from bare metal.
Jack
Chicago, IL
@ Toby Dr_A "Will that design be coming out to play, or is a comertial venture ?", It is all open source. There is the schematic posted on this thread a week or two ago, though it has changed slightly as it evolved. And it may change again - eg I built it for vga, but I got a 4" TV screen the other day so I'd like to try TV as well. Cluso (very wisely!) put both options on the triblade. I've got another board being made that has all the mods on it and I'll probably have a few spare.
Still some code changes to make. Ideally I'd like to have a drop in object that does the driving for this particular board and then a single ifdef at the beginning of the code that selects the triblade or the dracblade. Then all the software options can move forward as one single piece of code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Jack: Welcome to the madhouse !!
Toby: A friend of mine in New Zealand has re-bought a few Nascoms and he has a prop proto which I helped him interface to a Motorola D2 - replaces the keyboard and 7 seg display board with a prop with either keyboard + VGA or PC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Jack: Welcome, this is not a mad house, we are just psychedelic relics. Good luck with the TriBlade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There are a few other places that could·save a jump by reorganising code.
Need to get back to a Release version 1.0 first !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The last time I saw a Nascom2 for sale, was about a year ago. It was in Holland and cost 300 euros +++. I then realized that all the old stuff I didn't have anymore would be worth a fortune.
Where is that cat ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point