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.
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.
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
add L, #1
test L, #$100 WC
and L, #$ff
addx H, #0
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.
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
SET SIO PORT=Port/Terminal/Read/NotRead/Write/Reset/Reset/Data
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
; 3. Read reader
; 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.
; 33. Read randomly.
; 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!
READ_CONSOLE: ; returns answer in A
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*
Added the last two lines
PRI on_input
'Handle Z80 IO port reads
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.
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. 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.
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."
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
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?
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.
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.
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.
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
__outa res 1 ' read/write
alu long ' arithmetic logic unit (sort of :)
__outb res 1 ' read/write
__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
__ctra res 1 ' read/write
daa_adj long ' adjustment value for DAA (reused)
__ctrb res 1 ' read/write
ea long ' effective address
__frqa res 1 ' read/write
tmp long ' second operand temp
__frqb res 1 ' read/write
t1 long ' temporary 1
aux long ' auxiliary flag temp
__phsa res 1 ' read/write
vector long ' opcode vector
__phsb res 1 ' read/write
__vcfg res 1 ' read/write - leave this alone
lmm_pc long ' LMM program counter
__vscl res 1 ' read/write
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
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!
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
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.
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!
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.
>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....
Comments
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
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.
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 add L, #1 test L, #$100 WC and L, #$ff addx H, #0 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_endcpir 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
cpi<r>........................( 6,144) cycles OK
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
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
SET SIO PORT=Port/Terminal/Read/NotRead/Write/Reset/Reset/Data
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 ; 3. Read reader ; 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. ; 33. Read randomly. ; 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! READ_CONSOLE: ; returns answer in A 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 ENDHelp 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*
Added the last two lines
PRI on_input 'Handle Z80 IO port reads 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 deviceNow to work on the PRI on_output
ok, got that working. You can output to port 2 already with these port numbers
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 2This 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
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.
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
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· 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
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?
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· 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
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
My board says
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
test_flag_false mov alu, vector shr alu, #18 andn alu, flags wz, nr jmp #vect_wThis 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_flagsThis 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
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
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· 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
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 __outa res 1 ' read/write alu long ' arithmetic logic unit (sort of :) __outb res 1 ' read/write __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 __ctra res 1 ' read/write daa_adj long ' adjustment value for DAA (reused) __ctrb res 1 ' read/write ea long ' effective address __frqa res 1 ' read/write tmp long ' second operand temp __frqb res 1 ' read/write t1 long ' temporary 1 aux long ' auxiliary flag temp __phsa res 1 ' read/write vector long ' opcode vector __phsb res 1 ' read/write __vcfg res 1 ' read/write - leave this alone lmm_pc long ' LMM program counter __vscl res 1 ' read/write▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/10/2010 10:09:47 AM GMT
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· 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
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!
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
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· 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
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.
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!
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.
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....