ZiCog a Zilog Z80 emulator in 1 Cog - Page 36 — Parallax Forums

# ZiCog a Zilog Z80 emulator in 1 Cog

• Posts: 817
edited 2010-03-17 08:20
heater said...
CPD/CPI<r> Still no go.

I have no time to look at this, we are busy preparing some software for an exhibition/trade show in Amsterdam next week. Does not help that the show is one month earlier than my boss thought it was when he said we should attend!

Oh, that's pretty normal in our business, or is it? I hear nothing from my contractors for weeks or even month. Then they want something and it had to be done by yesterday.

Darn CPx! I forgot to do the sign flag in CPI and CPD. Last try.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
• Posts: 817
edited 2010-03-17 08:22
Toby Seckshund said...
Heater

The solution is always required yesterday ( or the day before )

Exactly! *me* twiddles thumbs waiting for my contractor to transfer some duties...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
• Posts: 3,370
edited 2010-03-17 08:26
Damn, just made it into the office. Can't try out CPx till I get home again which might be another 12 hours away.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
• Posts: 817
edited 2010-03-17 09:31
heater said...
Damn, just made it into the office. Can't try out CPx till I get home again which might be another 12 hours away.
Doesn't matter. It will be ok
Meanwhile I got rld/rrd working and am fighting with the Z80 overflow (P/V) flag on add/adc/sub/sbc. This one is really hairy.
The formula in MAME is V = ((alu^tmp^0x80) & (accu^tmp) & 0x80) ? 1 : 0; where alu is the result, accu the original value and tmp the addend/subtrahend.
That is no sign difference between result and addend/subtrahend AND sign difference between original value and addend/subtrahend.

Hmm.. wait! I just saw that your implementation of the aluops is working! I think I'm going to steal them [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.

Post Edited (pullmoll) : 3/17/2010 9:58:23 AM GMT
• Posts: 3,370
edited 2010-03-17 10:25
Steal away !

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
• Posts: 3,370
edited 2010-03-18 04:44
Just a quick EX run before it's back to the office for another 12 hour day...

cpd<r>........................( 6,144) cycles ERROR **** crc expected:c8439345 found:d7986667
cpi<r>........................( 6,144) cycles ERROR **** crc expected:e66fa7d2 found:f9b452f0

[noparse]:([/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
• Posts: 817
edited 2010-03-18 06:50
heater said...
Just a quick EX run before it's back to the office for another 12 hour day...

cpd<r>........................( 6,144) cycles ERROR **** crc expected:c8439345 found:d7986667
cpi<r>........................( 6,144) cycles ERROR **** crc expected:e66fa7d2 found:f9b452f0

[noparse]:([/noparse]

Himmelherrgottsakrament!

Here's my working do_cpi function:
```do_cpi        long    (do_cpi_end - \$ - 1)
call    #rd_byte_hl
mov    tmp, alu
and    F, #CF            ' keep C flag
or    F, #NF            ' set N flag
test    L, #\$100    WC
and    L, #\$ff
and    H, #\$ff
sub    C, #1        WC
and    C, #\$ff        WZ
subx    B, #0
if_z    and    B, #\$ff        WZ
if_nz    or    F, #PF            ' set P flag if BC is non zero
mov    alu, A
mov    aux, alu        ' keep a copy in aux for H flag
sub    alu, tmp    WZ
muxz    F, #ZF            ' set Z from zero
test    alu, #\$80    WZ
muxnz    F, #SF            ' set S from bit #7
xor    aux, alu
xor    aux, tmp
and    aux, #HF
or    F, aux            ' set H from change of bit #4
do_cpi_end

```

cpir does exactly the same and then jumps back to the start if Z is clear and P is set.

I hope the trial-and-error cycles will be shorter soon, once I can compile zicog and run tests here.
This time cpi and cpd were ok, but cpir and cpdr still lacked the partiy = bc <> 0 test.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.

Post Edited (pullmoll) : 3/18/2010 9:39:16 AM GMT
• Posts: 3,370
edited 2010-03-18 20:36
cpd<r>........................( 6,144) cycles OK
cpi<r>........................( 6,144) cycles OK

[noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
• Posts: 5,484
edited 2010-03-18 22:06
That is another 2 nailed. Well done!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
• Posts: 5,484
edited 2010-03-23 10:50
Hi heater et al,

I'm looking at getting kermit working for file transfers. There is a generic version of kermit that uses CP/M bios calls and these are can be set up so output is the the 'Punch' device (bios call 4) and 'Reader' device (bios call 3).

I'm not sure if these are programmed into the SIMH version we are using becase I can't seem to be able to trap these with the io_byte routine. I found some bits of code in spin
punstat = \$12 ' (18)sio port 2 status port
pundata = \$13 ' (19)sio port 2 data port

I think it is something to do with this command on the simh

Anyway, attempts to trap an output to a ptp (paper tape punch) either in pip or in assembly have failed. I was hoping it would tell me there was an unimplemented port, but it just hangs the zicog.

This is my little test program PUNCH.MAC and it sends one character to the console then one character to the PUNCH device
```; changing from tasm mnemonics - replace all \$nn with nnH
; remove . in front of equ
; remove : in equ lines
; must have a CR/LF after END
; no org 100 in mac programs - it is implied
; use zasm.sub with supersub
; eg supersub zasm myfile    (where myfile is called myfile.mac but do not put the
;                             mac in the instruction - m80 knows it is implied)
; zasm.sub is the following two lines
;M80 =\$1 /Z/C/L/M
;L80 \$1,\$1/N/E

START:

JP MAIN

; 1. Read console - returns an ascii character
; 2. Write console - Sends an ascii character
; 4. Write punch
; 5. Write list
; 6. Direct console input/output. Send FF to receive character status
; 7. Get I/O status of device
; 8. Set I/O status
; 9. Print buffer. Send entire string starting with address and ending With \$
; 10. Read buffer. Send address of buffer and return with filled buffer
; 11. Interrogate console ready (If LSB is 1 then console character is ready)
; 12. Lift disk head and return version number of CP/M
; 13. Reset disk system.
; 14. Select disk. 1=A, 2=B etc
; 15. Open file.
; 16. Close file.
; 17. Search for a file.
; 18. Search for next occurrence.
; 19. Delete file
; 20. Read sequentially the next 128 bytes.
; 21. Write sequentially the next 128 bytes.
; 22. Make new file and open it.
; 23. Rename file.
; 24. Return login vector (which disks are online).
; 25. Return current disk.
; 26. Set DMA address (to find data records in other parts of memory.Usually boot+80H)
; 27. Get allocation vector (for STAT to calculate remaining space)
; 28. Write protect disk.
; 29. Get read/write status of disk.
; 30. Set file attributes (read only etc)
; 31. Get disk parameter block address.
; 32. Get or set user code.
; 34. Write randomly.
; 35. Compute file size for random files.
; 36. Set random record position.

FDOS    EQU    0005H    ; COMMON ENTRY POINT FOR BIOS AND BDOS

MAIN:

LD E,65
CALL WRITE_CONSOLE
LD E,65
CALL WRITE_PUNCH

RET        ; back to cp/m

; ************************************************
; bdos calls that preserve registers
WARM_BOOT:
LD C,0
CALL FDOS
RET            ; probably doesn't need a RET!
LD C,1
CALL FDOS
RET
WRITE_CONSOLE:        ; prints letter in E
LD C,2        ; FUNCTION NUMBER
CALL FDOS
RET

WRITE_PUNCH:        ; prints letter in E
LD C,4        ; FUNCTION NUMBER
CALL FDOS
RET

END

```

Help would be most appreciated!

Addit: Getting close to the problem. It is a *read* that isn't working - ie it is trying to read the punch device status on port 18. Hmm - what should it expect? 0x00 and 0x01 or 0x00/0x255 or 32/33

*Solved*

```PRI on_input
case io_port
'    srport:                                             'Altair front panel switches register
'      in_srport
simhport:                                           'SIMH control port
in_simhport
constat:                                            'Console status port \$0F
in_constat
condata:                                            'Console data port
in_condata
punstat:
io_data := %00000011                              ' always allow the punch to output as it is an output device

```

Now to work on the PRI on_output

ok, got that working. You can output to port 2 already with these port numbers
```' UART constants for the second port (male D9)
port2_test      = \$7D                    ' to test if a byte is ready
port2_io        = \$78                    ' for input and output to port 2
port2_baud      = \$7C                    ' set baud rate multiple of 1200 eg 1=1200, 16=19200, 96=115200

```

I've also attached the punch device to port 2 as well.
```PRI on_output
'Handle Z80 IO port writes
'simhport        = \$FE
'hdskport        = \$fd                   ' control port for simulated hard disk
'vgatext.dec(io_port)
case io_port
'    ledport:                                            'An 8 bit parallel output with LEDs attached
'      out_ledport
simhport:                                           'SIMH control port \$FE
'      out_simhport
condata:                                            'Console data port \$11
out_condata
constat:                                            'Console status port
'      out_constat
punstat:
'      PrintStringCR(string("Unknown punch status"))    ' do nothing outputting the status                                  'Punch control port
pundata:                                            ' connect CP/M punch to port 2
out_port2                                         ' output to port 2

```

This is so cool. The wireless network is attached to port 2. I've got another wireless module coming in via another transceiver module to a RS232 to USB device, and that is on COM3. Teraterm is preconfigured to be COM3. So with one doubleclick on Teraterm I can listen to the network.

But the really great thing is this uses pre-written CP/M commands. eg PIP - the generic copy program. PTP is the paper tape punch, so I just typed
A>PIP PTP:=TEST.TXT

and the text from that file appeared on my teraterm screen.

Ok, now to get the 'reader' device working.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

Post Edited (Dr_Acula) : 3/23/2010 11:26:00 AM GMT
• Posts: 2,964
edited 2010-03-23 11:15
Hi Dr_Acula

If I know correctly it is same status bits as on 8251 Intels serial IC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
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
• Posts: 5,484
edited 2010-03-23 11:25
Hi Sapieha, yes I took a guess as there are many types of uarts and serial ICs.

con_status is the console status for the simh so I guess that pun_status would be the same and it is. It was
00000011%

But now I am stuck.

Punch and Reader should be seperate devices. Each should have a status byte and a data byte. But the SIMH combines them into one device, that uses port 18 for status and port 19 for data.

Normally the Reader would test port 18 to see if data is available and read it from port 19. The availability of data is set by the serial port object running in a cog and is set if Head is not equal to Tail

The problem is that to get the punch device to output, I set port 18 to say that it is always available. So now the reader assumes there is always a byte. I might need to ask Peter Schorn about this:
"The second port reads from an attachable "tape
reader" file on input, and writes to an attachable "punch file" on output. These files are considered a simple
stream of 8-bit bytes."

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

Post Edited (Dr_Acula) : 3/23/2010 11:39:39 AM GMT
• Posts: 18,069
edited 2010-03-23 16:08
I suspect that port 18 will return different bits for punch and reader status and you will have to and the appropriate bits. Port 19 is simple - if you read you will get a byte from the reader and if you write you will output a byte. Probably one UART is being used for both, so the status bits returnedfor Port 18 are no doubt a normal UARTs status bits.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)

· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
• Posts: 22
edited 2010-03-23 18:07

Because Blade #2 and #1 can be connected together by serial line, it is possible to make the stand alone CP/M computer.
Only the·PS/2·keyboard and TV or VGA monitor is needed for it.

Is·such project started already, or should I start it?

And which kind of terminal do you recommend to emulate?

·
• Posts: 18,069
edited 2010-03-23 19:02
Omikron: Absolutely. You need the VT100 terminal emulator for Blade #1. see my signature (terminals) for the links.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)

· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
• Posts: 5,484
edited 2010-03-23 22:50
Thanks cluso - yes I woke up in the middle of the night with a vague recollection in the SIMH manual talking about bits. I haven't read the manual as I'm at work now but I suspect that is the answer - different bits set for each port. At least I'm hoping that is the answer.

Re Omikron- yes you can build a standalone CP/M computer. See my avatar for a photo of one and link below. Everything is a compromise, and the choice is Cluso's two propeller solution which is faster, or the single propeller solution which is about 20% slower.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
• Posts: 22
edited 2010-03-25 17:46
HELP

My board says

```----------------------------------------
ZiCog 1.0_rc_6.0 on the TriBlade v0.150 96MHz
Starting HDisks...
A:ZICOG_A2.DSK 33600 8388608
B:ZICOG_B .DSK 49984 8388608
C:ZICOG_C .DSK 66368 33554432
D:ZICOG_D .DSK 131904 8388608
E:DRAC_A .DSK 832 8388608
F:DRAC_B .DSK 17216 8388608
G:ZICOG_G .DSK 181056 1048576
H:ZICOG_H .DSK 183104 1048576
BOOTHDSK.ROM 217984 1024 <-bootcode
Starting Z80... Done
----------------------------------------PC=FF43 AF=D344 BC=2058 DE=0000 HL=0000 IX=0000 IY=0000 SP=0000
```

and the register dump is still the same when I turn it off and on again
I tested the whole A and D buses and they seem to be OK

When #define SingleStep and #define ShowDiskAccess is on then it can be traced untill that address and then it says HDSK ERROR 2

Post Edited (Omikron) : 3/25/2010 9:32:22 PM GMT
• Posts: 817
edited 2010-04-08 21:41
Since many people seem to be using ZiCog, here's some more longs to save in the cog:
```test_flag_false   mov   alu, vector
shr     alu, #18
andn   alu, flags    wz, nr
jmp    #vect_w

```

This trick saves the xor flags,#\$ff that was there twice = 2 longs.

```alu_or               rdbyte  alu, a_reg          'Load A
andn    alu, data_8         'clear the bits to OR
jmp     #alu_xor_1
alu_xor             rdbyte  alu, a_reg
alu_xor_1         xor       alu, data_8 wz, wc
andn     flags, #aux_bit
jmp      #alu_logic_flags

```

This saves just one long, because I need the jump into the XOR code. The trick is to clear the bits that will be XORed to turn the XOR into an OR.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
• Posts: 5,484
edited 2010-04-10 08:39
That is a cunning trick.

In a broad sense, re "since many people seem to be using zicog" I'm not even sure exactly what I'm using on the dracblade now. I think it is a LMM 8080 emulation that has elements of zicog and elements of pullmoll's code and some LMM code as well. I'd love to move up to a full Z80 solution but I don't think it fits at the moment.

There are other elements of pullmoll's code I'd like to add, eg interrupt handling. It is a matter of adding things without breaking existing code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
• Posts: 817
edited 2010-04-10 08:55
Dr_Acula said...
In a broad sense, re "since many people seem to be using zicog" I'm not even sure exactly what I'm using on the dracblade now. I think it is a LMM 8080 emulation that has elements of zicog and elements of pullmoll's code and some LMM code as well. I'd love to move up to a full Z80 solution but I don't think it fits at the moment.

Just give me some more time. I'm working on the 3rd rewrite of the Z80 core, a mix of vectored cog code and LMM for instructions that are just too big for the cog. The core code (without interrupt handling) is currently down to 2562 longs. With interrupt code in place it's 2615 longs. The latest ZiCog I have is 1852 longs with the DracBlade. The latest yaz80 was 3196 longs.

I have all instructions emulated, just not the undocumented flag bits, and I still know a place where I could save abt. 40 longs for the cost of slower execution of the shift/rotate operations. Thinking about it I may even be able to get rid of the CB opcodes table by constructing the operand and opcode vector. That would be 128 longs minus the code needed to compose an opcode vector.

What I would suggest for whatever you're using now is changing the I/O communication to a single long. Instead of having I/O command, port and data in separate longs, I combined them into one long: bits 31..24 = command, 23..8 = port, 7..0 = data. This is faster and wastes less cog space. The new core tailored for the TRS80 has 1 just cog long left - even after moving internal variables to the \$1f0-\$1ff range.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects

Post Edited (pullmoll) : 4/10/2010 10:05:18 AM GMT
• Posts: 18,069
edited 2010-04-10 09:53
pullmoll: I hope you realise you cannot use all the \$1F0-\$1FF range as variables as some have different effects.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)

· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
• Posts: 817
edited 2010-04-10 10:00
Cluso99 said...
pullmoll: I hope you realise you cannot use all the \$1F0-\$1FF range as variables as some have different effects.
I asked here for the implications of using that range and I'm of course using only the bits that should not have an effect. The z80 cog doesn't use counters or i/o, so I think it's safe to use outa, outb, frqa, frqb, phsa, phsb and vscl full 32 bits. I also use ctra and ctrb, but just for small values, so the counter mode bits are not touched. Here's the map:
```        org    \$1f0
__par        res    1                ' read only
__cnt        res    1                ' read only
__ina        res    1                ' read only
__inb        res    1                ' read only
opcode        long                    ' most recent opcode
alu        long                    ' arithmetic logic unit (sort of :)
__dira        res    1                ' read/write - leave this alone
__dirb        res    1                ' read/write - leave this alone
postop        long                    ' operation after DD/FD CB disp8 xy
tmp        long                    ' second operand temp
t1        long                    ' temporary 1
aux        long                    ' auxiliary flag temp
vector        long                    ' opcode vector
__vcfg        res    1                ' read/write - leave this alone
lmm_pc        long                    ' LMM program counter

```

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects

Post Edited (pullmoll) : 4/10/2010 10:09:47 AM GMT
• Posts: 18,069
edited 2010-04-10 13:11
pullmoll: I use par, cnt, ina, inb as shadow registers for my executing my LMM debugger code and it works extremely well. However, as you stated, it is not possible to use them as gp registers.

I see no problems with using outa, outb, frqa, frqb, phsa, phsb, vscl providing the counters are disabled and vcfg is disabled although I have not tested them. I like the idea of using the lower bits of ctra, ctrb providing the upper bits are always 0 to ensure the counters are disabled.

This gives an extra 7 x 32 bit registers and 2 x 23 bit registers providing the upper bits are always 0.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)

· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
• Posts: 29
edited 2010-05-23 06:20
I'd like to try ZiCog with CPM and i have a lot of questions, i hope they will be answered [noparse]:)[/noparse]

I'm reading now for a while in this thread and read that the triblade is the "main-development" board. I had a look at the source code and couldn't find any code which is running outside of *1* cog. So i should be able to use ZiCog with only one propeller, a crystal+eeprom, Keyboard, TV-Out and SD-Card. Is that right?
Propably i'll try later adding more props...

I have installed the altairz80 emulator on my computer and did run cpm2.2 und cpm3. Which one should i choose? Does one of them not run on zicog?

In the altairz80-emulator i have a lot of ram. On the prop i only have 24k of ram, is that right? Do i need external ram? I don't have 3v3 ram, only 512kx8@5V for my 8051 chips...

I tried turbo pascal 1, 3 and bdsC in the emulator with 24k ram. The pascal compiler compiled mini calculator successful and bdsC compiled tail successful, but the bdsC manual says it needs about 40k ram.
Obviusly it works, but i'm sure there will be some errors due to lack of ram.

Can i use my altairz80-emu fdd/hdd-images?

Can i use a "OS" like PropDOS oder PropCMD in my propeller-eep to load ZiCog from sd card?

I can't understand why anyone should make a file system without directories...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
some say the devil is dead... ...tish army!
• Posts: 5,484
edited 2010-05-23 07:28
Hi Bazi, hopefully I can answer all those questions.

1) 1 cog is needed for the zicog. But you need other cogs to do things like the TV, keyboard, sd card. So all 8 cogs are used.
2) There was a very early version of zicog that runs on 24k of memory and will run on any propeller board. But you can't do much with that memory
3) There are a number of boards that add external memory - usually 512k. Triblade is one of those. Also Dracblade.
4) The 512k ram chips are 3V chip, 55ns. There might be a circuit that uses 5V memory chips but it would need resistors for level translation. And many 5V memory chips are not fast enough.
5) Yes you can use altair hard disk images. The current zicog/qZ80 emulation uses the 8mb hard drive image (drive i on the simh if you add it).
6) Yes using propdos to load zicog etc is a great idea. Lots of people have talked about doing it. No-one actually has. But it should be fairly easy to do.
7) The emulation uses CPM 2.2 or MPM. I think Cluso got CPM 3 working but I'm not sure.
8) No directories? Yes, this is a very old operating system. Maybe we could emulate an 8088 and do DOS. But there might be copyright problems with Microsoft.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
• Posts: 18,069
edited 2010-05-23 13:05
PropCmd is only an extended PropDos and PropDos is used by RamBlade to load ZiCog.

Bazi: You will need some form of external memory and that will take pins. On the TriBlade, a single prop is used for the SRAM, SD card, eeprom, optional flash, and 2 serial pins for comms to another prop. The RamBlade is a module that contains 512KB SRAM, prop + eeprom and SD card and 2 pins left for serial comms to another prop or PC running a terminal emulator, or alternately 1pin B&W TV and 1pin keyboard. DracBlade takes a different approach and uses 1 prop and lots of latches to drive the SRAM which sacrifices speed, but saves pins for other I/O uses.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)

· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
• Posts: 3,370
edited 2010-05-23 13:08
Hi Bazi,

Let's see.

Yes,TriBlade is the board I have been developing ZiCog on ever since a binned by home made Prop Demo Board style board.

ZiCog only uses one Prop chip though. It shows the CP/M output on your PC in a terminal window. I use the terminal Window of the BST tool.

You will need to compile ZiCog with BST anyway as it uses "#define" statements that the Parallax Prop tool does not support.

ZiCog does not support CP/M 3 yet.

You cannot use the disks from the AltairZ80 simulator as is. The floppy images are in a format that we decided was to awkward for ZiCog as well as being very slow to access. ZiCog exclusively uses the AltairZ80 8MB hard disk image format. But then you need the modified bootloader and that comes with ZiCog and the HD images need to have the ZiCog version of CP/M on the boot sectors.

So in short you need the HD disk images supplied with ZiCog to boot from. However you can use any othe AltairZ80 HD image as drive B:, C: etc.

On the TriBlade ZiCog uses 64K of the 512K external RAM for CP/M.

One makes a file system with out directories when you don't have enough memory space in your machine to hold the code to manage them. As in CP/M and FAT file systems on the Propeller.

Now if all that sounds complicated. Have no fear. There is an older version of ZiCog that will boot into CP/M using only 24K of Propeller HUB RAM, no ext RAM required. Might be a trouble to find it in this long thread. If you are up for it I will l have a look around on my machine here as well.

I'm not sure I'd go for adding a RAM chip to your Prop unless you can build exactly a TriBlade Blade# circuit or DrAcula's DracBlade. If you make it different you will spend a long time getting the RAM access code to work. Clusso and Dr_A have already done all that for us with their circuits[noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
• Posts: 29
edited 2010-05-23 14:27
Ok thanks!
two people said...
You will need some form of external memory and that will take pins.

I'm not sure I'd go for adding a RAM chip to your Prop unless you can build exactly a TriBlade Blade# circuit or DrAcula's DracBlade. If you make it different you will spend a long time getting the RAM access code to work. Clusso and Dr_A have already done all that for us with their circuits[noparse]:)[/noparse]
Building the RAM-circuits of these Boards wouldn't be a problem, but i don't have all these things here and i think thats too much work.
Isn't there a simple "standard"-way like adding a latch and the sram to a 8051?
I have a 32Kx8@5V with inputs down to 2V, but i don't know if its enough...

[noparse][[/noparse]quote]You will need to compile ZiCog with BST anyway as it uses "#define" statements that the Parallax Prop tool does not support.
I'm using it already, cause i have no windows [noparse]:D[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
some say the devil is dead... ...tish army!
• Posts: 3,370
edited 2010-05-23 14:41
No, there is no "standard" way to add external RAM to a Propeller.

External RAM is just bolted on to the normal I/O pins which are then driven by software like any other general purpose I/O. There are a number of such solutions, Clusso's RamBlade and TriBlade, Dr_Acula's DracBlade, the Hydra RAM expantion, Bill Henning's Morpheous and lets not for get Dr Jim's solution. Only the "...Blades" have been running ZiCog so far as far as I know.

You can probably use a 5v RAM provided you use current limiting resistors on the data bus. I'm no expert about that. But you would then have to hack the ZiCog code to access your RAM if you use your own circuit invention.

>> "I'm using it [noparse][[/noparse]BST] already, cause i have no windows [noparse]:D[/noparse]"

Excellent[noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
• Posts: 29
edited 2010-05-23 14:52
>You can probably use a 5v RAM provided you use current limiting resistors on the data bus. I'm no expert about that. But you would then have to >hack the ZiCog code to access your RAM if you use your own circuit invention.

Thats (expletive), i've been using 5V sram with an AVR running at 3.3V. The limiting resistors were 100ohm, this didn't work reliable. After days of debugging i wrote a ramcheck-program. It wrote random patterns, read them and gave an error if they weren't equal, I got about 5...15 errors per check...

So, the only wise way to ZiCog is to order and wait....