If you have both the floppy and hard drive under SIMH, could you not have a blank 1MB hard drive ($E5) and put the boot system onto it and PIP all files from the floppy to it. This would take care of the sector skewing and 137 byte format in one hit ????
BTW how did you get the hdp running? My drive C: is still a floppy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Maybe I'm missing a point here but I'm suffering from "chicken and egg" syndrome.
You may be right but I can't convince myself of why yet.
However I just found I could attach a floppy disk image to SIMH as a dsk or an hdsk and it comes up readable both ways!!
This tells me there is something going on here I don't understand yet.
Still, the boot tracks are identical on hard and floppy disks (skew does not apply) so a BOOTGENed 1MB floppy which is otherwise blank to E5 should boot up as a floppy or HD.
Time for an experiment...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Our normal old CBIOS (before I started removing floppy support) will always treat the first 8 drives as Altair floppies no matter what we put in those hdp tables. The first entry dpb_0 is always drive I:
What should we do to get your latest zicog_demo changes merged to the up and coming one from me ?
I stopped looking at the changes you made in 107 when I found the output of diff is over 900 lines long !!!
(yes I know many of those are comment indentation changes)
Now I'd like to put up a zicog_demo with
1) Packed disks
2) All Altair floppy driver code removed.
3) Changes to the dpb tables for 1M drives.
4) A few other lines here and there to support the new packed disk routines.
That's already a lot but its get worse.
There is now a new CBIOSX.COM.
And the the disk images in FAT have to change.
I/we need you to tweek the new packed HD routines for the TriBlade.
So should I just dump all this on you at some point !!!???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
How to make a bootable 1MB disk usable as a hdsk under SIMH and ZiCog.
I think I've cracked it. The trick is that in SIMH one can specify the geometry of hard drives before starting the emulator by putting something like this in the config file:
attach hdsk1 new.dsk
set hdsk1 geom=254/32/128
That is 254 tracks, 32 sectors, 128 bytes per sector. Just like an old Altair floppy but no 137 byte sectors.
You can then start SIMH and XFORMAT the new disk then BOOTGEN the boot sectors on to it.
It's a bit more tricky than that as you have to get the steps in the right order else either XFORMAT or BOOTGEN complains about the disk format with a sector error !!!
So here is a HOWTO document that shows a working example.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hmm, That is still not quite what we want as XFORMAT (or SIMH) has reserved a huge number of directory entries so it is probably laid out like an hdsk after all. BUT no skew anyway !
Perhaps we just have to crate the empty bootable disk under SIMH and then PIP the files on to it under ZiCog. More experiments .....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: I have been doing hardware so nothing on the ZiCog front from me. When you are done, send me your demo file.
Yes I tried to change the size of drives I & J with both hdp_0 and hdp_1 but no luck as it still reported 8MB. That was even after I started with $E5 and PIP.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Changed dsmhigh to 00 instead of 07 and left dsmlow at F9
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
MBASIC COM 24K
1 File(s), occupying 24K of 416K total capacity
1023 directory entries and 392K bytes remain on I:
I>
Mind you, it is crashing now after expanding it back up to 8mb, so might need to start with a clean disk image there. But it does shrink down changing dsmlow and dsm high
Ok working now I've gone for a clean image and gone back to the original variables.
0 File(s), occupying 0K of 8136K total capacity
1024 directory entries and 8136K bytes remain on I:
I>
So - shrinking works, but expanding might need a clean image.
I tried some other combos with dsmlow and dsmhigh and they shrink and expand as expected in a proportional way, though I'm not quite sure how the maths works. 07F9H = 8136k
I think you have to be careful messing with those parameters they are all interrelated.
In my setup now I have no Altair floppy drives all goes through HD and those tables.
I have A: and B: defined as normal 8M drives. C: and are 1MB using the Altair floppy dpb entries I found in the CBIOSX.MAC.
My dpb tables are shown with the results below:
hdsk_dpb
dpb_0 '8MByte Default SIMH Altair HDSK params
:spt_low BYTE $20 'sectors per track (low byte)
:spt_high BYTE $00 'sectors per track (high byte)
:bsh BYTE $05 'data allocation Block SHift factor
:blm BYTE $1F 'data allocation block mask
:exm BYTE $01 'EXtent Mask
:dsm_low BYTE $F9 'maximum data block number (low_byte)
:dsm_high BYTE $07 'maximum data block number (high_byte)
:drm_low BYTE $FF 'total number of directory entries (low byte)
:drm_high BYTE $03 'total number of directory entries (high byte)
:al0 BYTE $FF 'determine reserved directory blocks
:al1 BYTE $00 'determine reserved directory blocks
:cks_low BYTE $00 'size of directory ChecK vector (low byte)
:cks_high BYTE $00 'size of directory ChecK vector (high byte)
:off_low BYTE $06 'number of reserved tracks (offset) (low byte)
:off_high BYTE $00 'number of reserved tracks (offset) (high byte)
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $00 'Physical record SHift factor, CP/M 3
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $00 'PHhysical record Mask, CP/M 3
:ss_low BYTE $80 'Sector Size (low byte)
:ss_high BYTE $00 'Sector Size (high byte)
'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks.
dpb_1 'Default 8MByte SIMH Altair HDSK params
:spt_low BYTE $20 'sectors per track (low byte)
:spt_high BYTE $00 'sectors per track (high byte)
:bsh BYTE $05 'data allocation Block SHift factor
:blm BYTE $1F 'data allocation block mask
:exm BYTE $01 'EXtent Mask
:dsm_low BYTE $F9 'maximum data block number (low_byte)
:dsm_high BYTE $07 'maximum data block number (high_byte)
:drm_low BYTE $FF 'total number of directory entries (low byte)
:drm_high BYTE $03 'total number of directory entries (high byte)
:al0 BYTE $FF 'determine reserved directory blocks
:al1 BYTE $00 'determine reserved directory blocks
:cks_low BYTE $00 'size of directory ChecK vector (low byte)
:cks_high BYTE $00 'size of directory ChecK vector (high byte)
:off_low BYTE $06 'number of reserved tracks (offset) (low byte)
:off_high BYTE $00 'number of reserved tracks (offset) (high byte)
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $00 'Physical record SHift factor, CP/M 3
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $00 'PHhysical record Mask, CP/M 3
:ss_low BYTE $80 'Sector Size (low byte)
:ss_high BYTE $00 'Sector Size (high byte)
'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks.
dpb_2 '1MByte Altair mits2 floppy as HDSK params
:spt_low BYTE $20 'sectors per track (low byte)
:spt_high BYTE $00 'sectors per track (high byte)
:bsh BYTE $04 'data allocation Block SHift factor
:blm BYTE $0F 'data allocation block mask
:exm BYTE $00 'EXtent Mask
:dsm_low BYTE $EF 'maximum data block number (low_byte)
:dsm_high BYTE $01 'maximum data block number (high_byte)
:drm_low BYTE $FF 'total number of directory entries (low byte)
:drm_high BYTE $00 'total number of directory entries (high byte)
:al0 BYTE $F0 'determine reserved directory blocks
:al1 BYTE $00 'determine reserved directory blocks
:cks_low BYTE $00 'size of directory ChecK vector (low byte)
:cks_high BYTE $00 'size of directory ChecK vector (high byte)
:off_low BYTE $06 'number of reserved tracks (offset) (low byte)
:off_high BYTE $00 'number of reserved tracks (offset) (high byte)
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $00 'Physical record SHift factor, CP/M 3
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $00 'PHhysical record Mask, CP/M 3
:ss_low BYTE $80 'Sector Size (low byte)
:ss_high BYTE $00 'Sector Size (high byte)
'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks.
dpb_3 '1MByte Altair mits2 floppy as HDSK params
:spt_low BYTE $20 'sectors per track (low byte)
:spt_high BYTE $00 'sectors per track (high byte)
:bsh BYTE $04 'data allocation Block SHift factor
:blm BYTE $0F 'data allocation block mask
:exm BYTE $00 'EXtent Mask
:dsm_low BYTE $EF 'maximum data block number (low_byte)
:dsm_high BYTE $01 'maximum data block number (high_byte)
:drm_low BYTE $FF 'total number of directory entries (low byte)
:drm_high BYTE $00 'total number of directory entries (high byte)
:al0 BYTE $F0 'determine reserved directory blocks
:al1 BYTE $00 'determine reserved directory blocks
:cks_low BYTE $00 'size of directory ChecK vector (low byte)
:cks_high BYTE $00 'size of directory ChecK vector (high byte)
:off_low BYTE $06 'number of reserved tracks (offset) (low byte)
:off_high BYTE $00 'number of reserved tracks (offset) (high byte)
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $00 'Physical record SHift factor, CP/M 3
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $00 'PHhysical record Mask, CP/M 3
:ss_low BYTE $80 'Sector Size (low byte)
:ss_high BYTE $00 'Sector Size (high byte)
A>ls a:
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
ASM COM 8K ! CPMBOOT COM 12K ! FORMAT COM 4K ! MOVER PRN 4K
BDOS COM 4K ! CREF80 COM 4K ! GO COM 0K ! PIP COM 8K
BDOS MAC 68K ! DDT COM 8K ! HALT COM 4K ! SHOWSEC COM 4K
BDOS PRN 168K ! DIF COM 4K ! HDSKBOOTMAC 8K ! STAT COM 8K
BOOT COM 4K ! DO COM 4K ! L80 COM 12K ! SUBMIT COM 4K
BOOT MAC 4K ! DSKBOOT COM 4K ! LIB80 COM 8K ! SURVEY COM 4K
BOOTGEN COM 4K ! DSKBOOT MAC 8K ! LOAD COM 4K ! SURVEY MAC 16K
CBIOSX COM 4K ! DUMP COM 4K ! LS COM 4K ! SYSCOPY COM 4K
CBIOSX MAC 52K ! EC8080 LIB 4K ! LU COM 20K ! SYSCPM2 SUB 4K
CBIOSX PRN 104K ! ECZ80ALLLIB 4K ! M80 COM 20K ! UNCR COM 8K
CCP COM 4K ! ECZ80DOCLIB 4K ! MC SUB 4K ! UNERA COM 4K
CCP MAC 28K ! ED COM 8K ! MCC SUB 4K ! UNERA MAC 16K
CCP PRN 76K ! EX MAC 56K ! MCCL SUB 4K ! XFORMAT COM 4K
CFGCCP LIB 4K ! EX8080 COM 12K ! MOVER COM 4K ! XSUB COM 4K
COPY COM 4K ! EXZ80DOCCOM 12K ! MOVER MAC 4K
59 File(s), occupying 880K of 8136K total capacity
951 directory entries and 7256K bytes remain on A:
A>ls b:
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
DSKBOOT MAC 8K
1 File(s), occupying 8K of 8136K total capacity
1023 directory entries and 8128K bytes remain on B:hdsk param
A>ls c:
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
MOVER MAC 2K
1 File(s), occupying 2K of 984K total capacity
255 directory entries and 982K bytes remain on C:hdsk param
A>ls d:
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
HDSKBOOTMAC 6K
1 File(s), occupying 6K of 984K total capacity
255 directory entries and 978K bytes remain on D:hdsk param
A>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Coming soon to the TriBlade...
New custom CBIOSX for ZiCog.
Eight hard disk driver for CP/M on SD.
6 * 8Mb + 1Mb Altair floppy style + 440K RAM for disk.
No Altair floppy support in BIOS.
Approx 1 second boot time.
New boot loader for hard disk boot (ZIBOOT.COM).
Just tidying and making the package now...
ZiCog 1.0_rc_3 on the Prop Demo Board
Starting disks (A:B:C:D:E:F:G:H:) ...
Passed, please wait...
Starting 8080 emulation...
Passed, please wait...
24K CP/M Version 2.2 (ZiCog, BIOS V1.27_Zi01, 8 HD, 05-Sep-2009)
A>b:
B>c:
C>d:
D>e:
E>f:
F>g:
G>h:
H>a:
A>survey
*** System Survey (June 82) ***
Drive A: 924K bytes in 75 files with 7244K bytes remaining
Drive B: 32K bytes in 0 files with 8136K bytes remaining
Drive C: 32K bytes in 0 files with 8136K bytes remaining
Drive D: 32K bytes in 0 files with 8136K bytes remaining
Drive E: 32K bytes in 0 files with 8136K bytes remaining
Drive F: 32K bytes in 0 files with 8136K bytes remaining
Drive G: 8K bytes in 0 files with 984K bytes remaining
Drive H: 14K bytes in 1 files with 434K bytes remaining
Memory map:
0 8 16 24 32 40 48 56 64
| | | | | | | | |
TTTTTTTTTTTTTTTTCCCBBBBBRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
T=TPA C=CPM B=BIOS or unassigned R=ROM or bad
BIOS at 4E03 iobyte 00 drive 00 BDOS at 4006
24576 Bytes RAM 40958 Bytes ROM 16390 Bytes in TPA
1 Bytes Empty 65534 Total Active Bytes
Active I/O ports:
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
.
.
.
254 Ports active
A>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm following the progress eagerly - all very exciting. So, drive G is the floppy drive? Does that mean you are booting from the system tracks of drive A? And how are you creating the drive A image now?
Thing is that all drives are now handled by the SIMH hard drive interface no matter what size/geometry they have. So they all get a speed up because the HD driver used DMA/block move. We can define whatever size/geometry we like in the dpb tables in Spin and attach them to whatever drive letter we like without having to hack and rebuild the CBIOS.
Also means that the disks have no sector skew which means our packed sector system gets to do a lot of sequential access's for more speed [noparse]:)[/noparse]
I removed all the floppy driver support from the CBIOSX so as to keep the BIOS down to a reasonable size when adding more HDs. Eight should be enough (?)
Downside is that regular SIMH Altair floppy images are no longer usable.
Drive G: and H: are defined as two different size "floppies" by way of examples and to prove it works.
Currently the thing boots from drive A: The boot drive is actually set in the ROM boot loader code so we can make that flexible as well.
That drive A: is an exact copy of my SIMH I: drive put onto my SD card with no preprocessing[noparse]:)[/noparse]
I create it by PIPing the files from a modified cpm2.dsk to I: under SIMH and then make it bootable with:
BOOTGEN CPMBOOT.COM I:
after having built a CP/M with the new version of CBIOSX.
Just cleaning up and testing and I'll put this up for your perusal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My CP/M skynet just went live today. Well, maybe not skynet, but I have a board sitting in a shed 100 metres from my house and it is running some sbasic code, and I'm inside a steel frame house with a steel roof and I know that 2.4Ghz wifi can't get even go half the distance to the shed, and yet I can sit here and type PING <BOARDNAME> and 1 second later I get PONG back. Wifi and this network are both 10mW, but that is the cool thing about 433Mhz vs 2.4Ghz, plus the super sensitive -123db gain on the Rx.
Wireless CP/M goes further than Wifi!
Next challenge - get the zicog/triblade into the network. The triblade uses much less power, and that is important when running on solar. Or robotics. There is a bit of a catch though - the CP/M network runs at only 1200 baud (it could run faster but slower baud rates=longer distance) and I've been talking at 38400 then changing on the fly to 1200. For that, I need a few ports. I was wondering if I could please reserve ports 96,97,98,99,104,105 106 and 107? I don't think those clash with any being used by other bits of code.
The other catch is that this really needs two RS232 connections. Or 1 connection, and one local keyboard and one local display. So you can type things into the board and see the printout, but not have those bytes going out onto the airwaves. On the N8VEM the local display is an LCD display using 6 wires. There must be a cunning way to do that. eg - Q7 on the HC573 isn't going anywhere - could I run that to pin 11 on another latch chip, and run the data lines into that latch chip, and with just one more chip add a 20x4 LCD display?? Or does the new board/design render this sort of thing obsolete?
But before that, I guess the next thing is to get heater's code into a triblade. Heater, if you put just the minimum files on your drive I> (now drive A>) and zip it, how small does it go? Or is bootgen really that simple?! And, I guess I've asked this before, are you not running a triblade because of a) lack of a sd socket or b) lack of a ram chip? I've got some spare ram chips (I didn't need to make the missiles after all) and ?? does cluso have a sd socket? It is just it could really simplify things if we all had the same hardware.
At the risk of sounding like Mallred I have to announce that I cannot reveal the latest OS just yet. No, you see I have developed all this for a secret military high reliability, low power, global wireless networking project that will remain functional during the nuclear winter, slap, Err umm no sorry, I have to go shopping before the wife gets home from work....
Interesting what you say about 433MHz, here in Scandinavia they are now recycling the old mobile phone band at 450 MHz for use in data communication for remote systems such as equipment status monitoring etc. We are hoping to get such a modem for evaluation soon.
I'm sure we could reserve the ports. I was thinking we may want to move the port addresses around (or mirror them) to accommodate PropIO which has limited I/O addressing. Lets see what we can do. It's all up for grabs on the Triblade as SIMH Altair compatibility has gone out the window.
Funny, the first time I got a CP/M prompt up on the Prop was with a 2 line LCD panel I had knocking around. That and a LED for debugging.
A zipped 8Mb A: disk is a whopping 376K bytes !!
Building CP/M with the new BIOS and using BOOTGEN is dead easy under SIMH. I will package up all required sources and some instructions with the next posting.
Boot up is about 1 second. But I'm starting from files in HUB. Still that directory scanning is damn quick now.
I would very much appreciate a RAM chip or two. I have now managed to obtain from the black market 2 DIP propellers including the last one the wild in Scandinavia. Most other parts are easy to get here.
OK, see you when I'm back from the bunker, err, shopping mall...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Dr_A: Maybe you can draw a block diag of the connections you require? I am not quite sure of your config - what is standard, what you want to add, if this is permanently connected or just plugged in when you are "there", etc. Sure, almost anything is posible (except AI - for now anyway), but what is the best/easiest/fastest way to achieve this depends on what you are after.
I gather the LCD display is 6 pins plus power, so I presume 1 must be a strobe.
Are you using Blade #1 as a Terminal? If so, then you probably don't require the sram or latch which frees uo some prop pins and they can be "tapped" from the latch pins meaning they will take a SIL row of pins.
Rereading your post, I presume you are wanting to use just 1 prop with a 2 wire serial to interface to the wireless. Does the other interface (keyboard and LCD) need to be permanently attached, or is it just plugged in for testing? I presume the latter as you would not want to waste the power. If this is so, then there is an easier way if you only need 128KB SRAM. We can save the latch too! RetroBlade could do this too.
Today I saw a version of jazzed's 1.5" keychain photoframe for A$20 at JB HiFi. They had a 5" photoframe for $50 (I think). I bought a 2.5" from Target a month or so ago for about $25??? but it was aclearance sale and I couldn't find any more.
Heater: see the top of this thread for a simple build of Blade #2 to get ZiCog running - this is what I m currently using Let me know what parts you don't have/can't get (I don't have any uSD or FT232RL left). An even simpler system woud be the prop, xtal, 1xSRAM, 1x74HC73 or 74LVC573, microSD and a 3V3 regulator, power connector plus r's and c's. Use an external PropPlug. You don't even require the eeprom nor the 5V reg.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Clusso I made up a copy of a blade2 months ago. I tested it with one of your routines 1M _202 or something like it and it came back with a bunch of lines about block reads and writes passing ok, then a rack of hex numbers and finished with i) complete.
Seemed ok (ish) but I have now found that nothing changed if one of the rams were removed, or if the second was removed as well leaving nothing left but the prop and the latch. Everything buzzes out ok and I do have the /OE mods ( from the start ). Any thoughts??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Attached is zicog_cpm_1_0_rc_3 a major revision of ZiCog for the Prop Demo Board and TriBlade.
Note: I have renamed zicog_demo.spin to zicog_cpm.spin.
The Good, the Bad and the Ugly release:
The Good:
1) Supports 8 * 8Mb CP/M disk drives on SD card. More is possible.
2) Supports SIMH Altair floppy disk sizes (1Mb) using the hard disk interface.
3) Includes a 440K disk definition for uses as RAM disk again using hard disk interface.
4) Now uses packed sectors. i.e. 4 * 128 byte sectors per SD block.
5) No sector skew on any disks, for speed in SD access.
6) Much faster. One second boot up.
7) SIMH AltairZ80 8Mb hard disk images are now usable directly with no pre-processing required.
8) Uses a modified SIMH CBIOSX with all floppy driver code removed, saves memory space.
9) Has a new ROM boot, ZIBOOT.COM that lives at FF00 (unlike SIMH's special set up in RAM) and boots from hard disk images.
10) Has no floppy driver support in Spin. This saves HUB memory, especially useful on Prop DemoBoard and generally simplifies things.
11) Now has 26Kb Z80 RAM space available on Prop Demo Board.
The Bad:
1) Can no longer use SIMH floppy disk images directly. SIMH floppies have sector skewing which we really don't want. N.B. My previous instruction for making disks do not work as expected.
2) I cannot get the new hard disk boot ROM code to work ZIBOOT.COM. Gets to the CP/M sign on message though then crashes. May be just not enough memory on the demo board, I had the same problem with the old DSKBOOT which works in 64K just fine. So CP/M must be written to RAM prior to start up.
3) Probably for the same reason as 2) PIP and other programs crash CP/M when finishing on the demo board as they do a warm boot.
3) Again for the same reason I could not get the AUTOEXEC initial command to function.
The Ugly:
1) This code is based on Cluso's _rr097 so I guess there are a lot of recent TriBlade mods outstanding.
2) TriBlade support is totally broken until Cluso can work his magic on it. Fortunately there is less code to tweak as we have no floppy drivers any more.
3) In order to salvage the 2K HUB RAM occupied by the CPU emulator PASM code I moved the Z80 RAM definition into zicog.spin such that the PASM code now lives in what becomes the Z80 RAM after the emulator COG is loaded.
As supplied the CP/M files CCP.COM, BDOS.COM, CBIOSX.COM are built for a 26K RAM system.
I might suggest getting those into TriBlade external RAM and getting CP/M running again before I rebuild CP/M for 64K.
So it looks like I have probably made a lot of work for you all but I think the benefits in speed and convenience are well worth it in the end.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: I have just looked at the differences. It should be pretty easy to combine the changes. I notice you have removed some now dead code and so have I so the result will be better. Off to do it now
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
1) My 26K RAM CP/M configuration does not actually fit in the HUB space available. For odd reasons it just looked like it did. Anyway 25K should be just fine.
2) Having loaded the boot sectors they seem to be in slightly the wrong location. Off by 256 bytes. Not sure yet why this happens as at first sight the whole load process looks the same as SIMH.
Dr_A: Did you say you had located the source of BOOTGEN.COM ?
What I'd like to do is make a new BOOTGEN customized for ZiCog.
You see the SIMH boot up reads alternate sectors of the first two disk tracks. This is a form of sector skew designed to speed up booting from floppy disks. Gives time for the next sector to rotate into place while storing the last sector read.
Of course this is exactly what we don't want for ZiCog with SD. We want to read sectors sequentially from SD card blocks for maximum speed.
Just an idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Actually the output of SYSCPM2.SUB is a file called CPMBOOT.COM which is a concatenation of MOVER.COM, CCP.COM, BDSO.COM and CBIOSX.COM.
I've just managed to place CPMBOOT.COM in Z80 RAM in HUB from a "file" statement (instead of all the separate .COM files). Now I can start CP/M from it.
Which is nice as it cleans up some of the "ugly" part in ZiCog.
So...I could just lay down the CPMBOOT.COM on the first sectors of the SD card (with no skewing) and the tweak ZIBOOT to just read those sequentially and start CP/M !
No need for a special BOOTGEN although it would be convenient.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just finished combining the code. Still need to do the few changes that TriBlade will require. · I also have to change the hub allocation as it will not compile - exceeds 32KB ··· I will post the update to this post in a few minutes.
re COMBOOT.COM·couldn't you just read them into hub via spin from the SD boot tracks, or better still, from a FAT16 file like I do??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Hmm... could do I guess. Can't fit FAT on the demo board but boot sectors would be fine.
Seems a bit like cheating though.
Still for now it would work a treat.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
If you have both the floppy and hard drive under SIMH, could you not have a blank 1MB hard drive ($E5) and put the boot system onto it and PIP all files from the floppy to it. This would take care of the sector skewing and 137 byte format in one hit ????
BTW how did you get the hdp running? My drive C: is still a floppy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (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
You may be right but I can't convince myself of why yet.
However I just found I could attach a floppy disk image to SIMH as a dsk or an hdsk and it comes up readable both ways!!
This tells me there is something going on here I don't understand yet.
Still, the boot tracks are identical on hard and floppy disks (skew does not apply) so a BOOTGENed 1MB floppy which is otherwise blank to E5 should boot up as a floppy or HD.
Time for an experiment...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Our normal old CBIOS (before I started removing floppy support) will always treat the first 8 drives as Altair floppies no matter what we put in those hdp tables. The first entry dpb_0 is always drive I:
What should we do to get your latest zicog_demo changes merged to the up and coming one from me ?
I stopped looking at the changes you made in 107 when I found the output of diff is over 900 lines long !!!
(yes I know many of those are comment indentation changes)
Now I'd like to put up a zicog_demo with
1) Packed disks
2) All Altair floppy driver code removed.
3) Changes to the dpb tables for 1M drives.
4) A few other lines here and there to support the new packed disk routines.
That's already a lot but its get worse.
There is now a new CBIOSX.COM.
And the the disk images in FAT have to change.
I/we need you to tweek the new packed HD routines for the TriBlade.
So should I just dump all this on you at some point !!!???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think I've cracked it. The trick is that in SIMH one can specify the geometry of hard drives before starting the emulator by putting something like this in the config file:
attach hdsk1 new.dsk
set hdsk1 geom=254/32/128
That is 254 tracks, 32 sectors, 128 bytes per sector. Just like an old Altair floppy but no 137 byte sectors.
You can then start SIMH and XFORMAT the new disk then BOOTGEN the boot sectors on to it.
It's a bit more tricky than that as you have to get the steps in the right order else either XFORMAT or BOOTGEN complains about the disk format with a sector error !!!
So here is a HOWTO document that shows a working example.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Perhaps we just have to crate the empty bootable disk under SIMH and then PIP the files on to it under ZiCog. More experiments .....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes I tried to change the size of drives I & J with both hdp_0 and hdp_1 but no luck as it still reported 8MB. That was even after I started with $E5 and PIP.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (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
Changed dsmhigh to 00 instead of 07 and left dsmlow at F9
Mind you, it is crashing now after expanding it back up to 8mb, so might need to start with a clean disk image there. But it does shrink down changing dsmlow and dsm high
Ok working now I've gone for a clean image and gone back to the original variables.
0 File(s), occupying 0K of 8136K total capacity
1024 directory entries and 8136K bytes remain on I:
I>
So - shrinking works, but expanding might need a clean image.
I tried some other combos with dsmlow and dsmhigh and they shrink and expand as expected in a proportional way, though I'm not quite sure how the maths works. 07F9H = 8136k
Post Edited (Dr_Acula) : 9/1/2009 2:28:31 PM GMT
In my setup now I have no Altair floppy drives all goes through HD and those tables.
I have A: and B: defined as normal 8M drives. C: and
My dpb tables are shown with the results below:
hdsk_dpb dpb_0 '8MByte Default SIMH Altair HDSK params :spt_low BYTE $20 'sectors per track (low byte) :spt_high BYTE $00 'sectors per track (high byte) :bsh BYTE $05 'data allocation Block SHift factor :blm BYTE $1F 'data allocation block mask :exm BYTE $01 'EXtent Mask :dsm_low BYTE $F9 'maximum data block number (low_byte) :dsm_high BYTE $07 'maximum data block number (high_byte) :drm_low BYTE $FF 'total number of directory entries (low byte) :drm_high BYTE $03 'total number of directory entries (high byte) :al0 BYTE $FF 'determine reserved directory blocks :al1 BYTE $00 'determine reserved directory blocks :cks_low BYTE $00 'size of directory ChecK vector (low byte) :cks_high BYTE $00 'size of directory ChecK vector (high byte) :off_low BYTE $06 'number of reserved tracks (offset) (low byte) :off_high BYTE $00 'number of reserved tracks (offset) (high byte) [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $00 'Physical record SHift factor, CP/M 3 [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $00 'PHhysical record Mask, CP/M 3 :ss_low BYTE $80 'Sector Size (low byte) :ss_high BYTE $00 'Sector Size (high byte) 'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks. dpb_1 'Default 8MByte SIMH Altair HDSK params :spt_low BYTE $20 'sectors per track (low byte) :spt_high BYTE $00 'sectors per track (high byte) :bsh BYTE $05 'data allocation Block SHift factor :blm BYTE $1F 'data allocation block mask :exm BYTE $01 'EXtent Mask :dsm_low BYTE $F9 'maximum data block number (low_byte) :dsm_high BYTE $07 'maximum data block number (high_byte) :drm_low BYTE $FF 'total number of directory entries (low byte) :drm_high BYTE $03 'total number of directory entries (high byte) :al0 BYTE $FF 'determine reserved directory blocks :al1 BYTE $00 'determine reserved directory blocks :cks_low BYTE $00 'size of directory ChecK vector (low byte) :cks_high BYTE $00 'size of directory ChecK vector (high byte) :off_low BYTE $06 'number of reserved tracks (offset) (low byte) :off_high BYTE $00 'number of reserved tracks (offset) (high byte) [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $00 'Physical record SHift factor, CP/M 3 [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $00 'PHhysical record Mask, CP/M 3 :ss_low BYTE $80 'Sector Size (low byte) :ss_high BYTE $00 'Sector Size (high byte) 'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks. dpb_2 '1MByte Altair mits2 floppy as HDSK params :spt_low BYTE $20 'sectors per track (low byte) :spt_high BYTE $00 'sectors per track (high byte) :bsh BYTE $04 'data allocation Block SHift factor :blm BYTE $0F 'data allocation block mask :exm BYTE $00 'EXtent Mask :dsm_low BYTE $EF 'maximum data block number (low_byte) :dsm_high BYTE $01 'maximum data block number (high_byte) :drm_low BYTE $FF 'total number of directory entries (low byte) :drm_high BYTE $00 'total number of directory entries (high byte) :al0 BYTE $F0 'determine reserved directory blocks :al1 BYTE $00 'determine reserved directory blocks :cks_low BYTE $00 'size of directory ChecK vector (low byte) :cks_high BYTE $00 'size of directory ChecK vector (high byte) :off_low BYTE $06 'number of reserved tracks (offset) (low byte) :off_high BYTE $00 'number of reserved tracks (offset) (high byte) [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $00 'Physical record SHift factor, CP/M 3 [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $00 'PHhysical record Mask, CP/M 3 :ss_low BYTE $80 'Sector Size (low byte) :ss_high BYTE $00 'Sector Size (high byte) 'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks. dpb_3 '1MByte Altair mits2 floppy as HDSK params :spt_low BYTE $20 'sectors per track (low byte) :spt_high BYTE $00 'sectors per track (high byte) :bsh BYTE $04 'data allocation Block SHift factor :blm BYTE $0F 'data allocation block mask :exm BYTE $00 'EXtent Mask :dsm_low BYTE $EF 'maximum data block number (low_byte) :dsm_high BYTE $01 'maximum data block number (high_byte) :drm_low BYTE $FF 'total number of directory entries (low byte) :drm_high BYTE $00 'total number of directory entries (high byte) :al0 BYTE $F0 'determine reserved directory blocks :al1 BYTE $00 'determine reserved directory blocks :cks_low BYTE $00 'size of directory ChecK vector (low byte) :cks_high BYTE $00 'size of directory ChecK vector (high byte) :off_low BYTE $06 'number of reserved tracks (offset) (low byte) :off_high BYTE $00 'number of reserved tracks (offset) (high byte) [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $00 'Physical record SHift factor, CP/M 3 [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $00 'PHhysical record Mask, CP/M 3 :ss_low BYTE $80 'Sector Size (low byte) :ss_high BYTE $00 'Sector Size (high byte)▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (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
New custom CBIOSX for ZiCog.
Eight hard disk driver for CP/M on SD.
6 * 8Mb + 1Mb Altair floppy style + 440K RAM for disk.
No Altair floppy support in BIOS.
Approx 1 second boot time.
New boot loader for hard disk boot (ZIBOOT.COM).
Just tidying and making the package now...
ZiCog 1.0_rc_3 on the Prop Demo Board Starting disks (A:B:C:D:E:F:G:H:) ... Passed, please wait... Starting 8080 emulation... Passed, please wait... 24K CP/M Version 2.2 (ZiCog, BIOS V1.27_Zi01, 8 HD, 05-Sep-2009) A>b: B>c: C>d: D>e: E>f: F>g: G>h: H>a: A>survey *** System Survey (June 82) *** Drive A: 924K bytes in 75 files with 7244K bytes remaining Drive B: 32K bytes in 0 files with 8136K bytes remaining Drive C: 32K bytes in 0 files with 8136K bytes remaining Drive D: 32K bytes in 0 files with 8136K bytes remaining Drive E: 32K bytes in 0 files with 8136K bytes remaining Drive F: 32K bytes in 0 files with 8136K bytes remaining Drive G: 8K bytes in 0 files with 984K bytes remaining Drive H: 14K bytes in 1 files with 434K bytes remaining Memory map: 0 8 16 24 32 40 48 56 64 | | | | | | | | | TTTTTTTTTTTTTTTTCCCBBBBBRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR T=TPA C=CPM B=BIOS or unassigned R=ROM or bad BIOS at 4E03 iobyte 00 drive 00 BDOS at 4006 24576 Bytes RAM 40958 Bytes ROM 16390 Bytes in TPA 1 Bytes Empty 65534 Total Active Bytes Active I/O ports: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F . . . 254 Ports active A>▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/5/2009 9:49:39 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (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
Thing is that all drives are now handled by the SIMH hard drive interface no matter what size/geometry they have. So they all get a speed up because the HD driver used DMA/block move. We can define whatever size/geometry we like in the dpb tables in Spin and attach them to whatever drive letter we like without having to hack and rebuild the CBIOS.
Also means that the disks have no sector skew which means our packed sector system gets to do a lot of sequential access's for more speed [noparse]:)[/noparse]
I removed all the floppy driver support from the CBIOSX so as to keep the BIOS down to a reasonable size when adding more HDs. Eight should be enough (?)
Downside is that regular SIMH Altair floppy images are no longer usable.
Drive G: and H: are defined as two different size "floppies" by way of examples and to prove it works.
Currently the thing boots from drive A: The boot drive is actually set in the ROM boot loader code so we can make that flexible as well.
That drive A: is an exact copy of my SIMH I: drive put onto my SD card with no preprocessing[noparse]:)[/noparse]
I create it by PIPing the files from a modified cpm2.dsk to I: under SIMH and then make it bootable with:
BOOTGEN CPMBOOT.COM I:
after having built a CP/M with the new version of CBIOSX.
Just cleaning up and testing and I'll put this up for your perusal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (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
My CP/M skynet just went live today. Well, maybe not skynet, but I have a board sitting in a shed 100 metres from my house and it is running some sbasic code, and I'm inside a steel frame house with a steel roof and I know that 2.4Ghz wifi can't get even go half the distance to the shed, and yet I can sit here and type PING <BOARDNAME> and 1 second later I get PONG back. Wifi and this network are both 10mW, but that is the cool thing about 433Mhz vs 2.4Ghz, plus the super sensitive -123db gain on the Rx.
Wireless CP/M goes further than Wifi!
Next challenge - get the zicog/triblade into the network. The triblade uses much less power, and that is important when running on solar. Or robotics. There is a bit of a catch though - the CP/M network runs at only 1200 baud (it could run faster but slower baud rates=longer distance) and I've been talking at 38400 then changing on the fly to 1200. For that, I need a few ports. I was wondering if I could please reserve ports 96,97,98,99,104,105 106 and 107? I don't think those clash with any being used by other bits of code.
The other catch is that this really needs two RS232 connections. Or 1 connection, and one local keyboard and one local display. So you can type things into the board and see the printout, but not have those bytes going out onto the airwaves. On the N8VEM the local display is an LCD display using 6 wires. There must be a cunning way to do that. eg - Q7 on the HC573 isn't going anywhere - could I run that to pin 11 on another latch chip, and run the data lines into that latch chip, and with just one more chip add a 20x4 LCD display?? Or does the new board/design render this sort of thing obsolete?
But before that, I guess the next thing is to get heater's code into a triblade. Heater, if you put just the minimum files on your drive I> (now drive A>) and zip it, how small does it go? Or is bootgen really that simple?! And, I guess I've asked this before, are you not running a triblade because of a) lack of a sd socket or b) lack of a ram chip? I've got some spare ram chips (I didn't need to make the missiles after all) and ?? does cluso have a sd socket? It is just it could really simplify things if we all had the same hardware.
And, I have to ask, how fast is your bootup now?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/5/2009 1:13:00 PM GMT
Interesting what you say about 433MHz, here in Scandinavia they are now recycling the old mobile phone band at 450 MHz for use in data communication for remote systems such as equipment status monitoring etc. We are hoping to get such a modem for evaluation soon.
I'm sure we could reserve the ports. I was thinking we may want to move the port addresses around (or mirror them) to accommodate PropIO which has limited I/O addressing. Lets see what we can do. It's all up for grabs on the Triblade as SIMH Altair compatibility has gone out the window.
Funny, the first time I got a CP/M prompt up on the Prop was with a 2 line LCD panel I had knocking around. That and a LED for debugging.
A zipped 8Mb A: disk is a whopping 376K bytes !!
Building CP/M with the new BIOS and using BOOTGEN is dead easy under SIMH. I will package up all required sources and some instructions with the next posting.
Boot up is about 1 second. But I'm starting from files in HUB. Still that directory scanning is damn quick now.
I would very much appreciate a RAM chip or two. I have now managed to obtain from the black market 2 DIP propellers including the last one the wild in Scandinavia. Most other parts are easy to get here.
OK, see you when I'm back from the bunker, err, shopping mall...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I gather the LCD display is 6 pins plus power, so I presume 1 must be a strobe.
Are you using Blade #1 as a Terminal? If so, then you probably don't require the sram or latch which frees uo some prop pins and they can be "tapped" from the latch pins meaning they will take a SIL row of pins.
Rereading your post, I presume you are wanting to use just 1 prop with a 2 wire serial to interface to the wireless. Does the other interface (keyboard and LCD) need to be permanently attached, or is it just plugged in for testing? I presume the latter as you would not want to waste the power. If this is so, then there is an easier way if you only need 128KB SRAM. We can save the latch too! RetroBlade could do this too.
Today I saw a version of jazzed's 1.5" keychain photoframe for A$20 at JB HiFi. They had a 5" photoframe for $50 (I think). I bought a 2.5" from Target a month or so ago for about $25??? but it was aclearance sale and I couldn't find any more.
Heater: see the top of this thread for a simple build of Blade #2 to get ZiCog running - this is what I m currently using
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (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
Clusso I made up a copy of a blade2 months ago. I tested it with one of your routines 1M _202 or something like it and it came back with a bunch of lines about block reads and writes passing ok, then a rack of hex numbers and finished with i) complete.
Seemed ok (ish) but I have now found that nothing changed if one of the rams were removed, or if the second was removed as well leaving nothing left but the prop and the latch. Everything buzzes out ok and I do have the /OE mods ( from the start ). Any thoughts??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I thought the code should be documented quite well so take a look at what the test is doing.
Put in an extra line of spin to force an error and see what happens
If you still have problems post what you have done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (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
Then there will be a race hazzard, Code sussed or wifey looking better, either way, BONUS!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
http://www.blogcatalog.com/blog/umicroelectronics-info-about-hobby-microcontrollers-and-microelectronics/cd8bc39dd4a99e83f4994e19edb94cfa
Don't know if there is anything of interest, to you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Note: I have renamed zicog_demo.spin to zicog_cpm.spin.
The Good, the Bad and the Ugly release:
The Good:
1) Supports 8 * 8Mb CP/M disk drives on SD card. More is possible.
2) Supports SIMH Altair floppy disk sizes (1Mb) using the hard disk interface.
3) Includes a 440K disk definition for uses as RAM disk again using hard disk interface.
4) Now uses packed sectors. i.e. 4 * 128 byte sectors per SD block.
5) No sector skew on any disks, for speed in SD access.
6) Much faster. One second boot up.
7) SIMH AltairZ80 8Mb hard disk images are now usable directly with no pre-processing required.
8) Uses a modified SIMH CBIOSX with all floppy driver code removed, saves memory space.
9) Has a new ROM boot, ZIBOOT.COM that lives at FF00 (unlike SIMH's special set up in RAM) and boots from hard disk images.
10) Has no floppy driver support in Spin. This saves HUB memory, especially useful on Prop DemoBoard and generally simplifies things.
11) Now has 26Kb Z80 RAM space available on Prop Demo Board.
The Bad:
1) Can no longer use SIMH floppy disk images directly. SIMH floppies have sector skewing which we really don't want. N.B. My previous instruction for making disks do not work as expected.
2) I cannot get the new hard disk boot ROM code to work ZIBOOT.COM. Gets to the CP/M sign on message though then crashes. May be just not enough memory on the demo board, I had the same problem with the old DSKBOOT which works in 64K just fine. So CP/M must be written to RAM prior to start up.
3) Probably for the same reason as 2) PIP and other programs crash CP/M when finishing on the demo board as they do a warm boot.
3) Again for the same reason I could not get the AUTOEXEC initial command to function.
The Ugly:
1) This code is based on Cluso's _rr097 so I guess there are a lot of recent TriBlade mods outstanding.
2) TriBlade support is totally broken until Cluso can work his magic on it. Fortunately there is less code to tweak as we have no floppy drivers any more.
3) In order to salvage the 2K HUB RAM occupied by the CPU emulator PASM code I moved the Z80 RAM definition into zicog.spin such that the PASM code now lives in what becomes the Z80 RAM after the emulator COG is loaded.
As supplied the CP/M files CCP.COM, BDOS.COM, CBIOSX.COM are built for a 26K RAM system.
I might suggest getting those into TriBlade external RAM and getting CP/M running again before I rebuild CP/M for 64K.
So it looks like I have probably made a lot of work for you all but I think the benefits in speed and convenience are well worth it in the end.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks heater. I will take a look tomorrow and report back.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (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
I have included instructions for generating CP/M 2 for ZiCog under AltairZ80 in a text file.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (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
1) My 26K RAM CP/M configuration does not actually fit in the HUB space available. For odd reasons it just looked like it did. Anyway 25K should be just fine.
2) Having loaded the boot sectors they seem to be in slightly the wrong location. Off by 256 bytes. Not sure yet why this happens as at first sight the whole load process looks the same as SIMH.
Dr_A: Did you say you had located the source of BOOTGEN.COM ?
What I'd like to do is make a new BOOTGEN customized for ZiCog.
You see the SIMH boot up reads alternate sectors of the first two disk tracks. This is a form of sector skew designed to speed up booting from floppy disks. Gives time for the next sector to rotate into place while storing the last sector read.
Of course this is exactly what we don't want for ZiCog with SD. We want to read sectors sequentially from SD card blocks for maximum speed.
Just an idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I've just managed to place CPMBOOT.COM in Z80 RAM in HUB from a "file" statement (instead of all the separate .COM files). Now I can start CP/M from it.
Which is nice as it cleans up some of the "ugly" part in ZiCog.
So...I could just lay down the CPMBOOT.COM on the first sectors of the SD card (with no skewing) and the tweak ZIBOOT to just read those sequentially and start CP/M !
No need for a special BOOTGEN although it would be convenient.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just finished combining the code. Still need to do the few changes that TriBlade will require.
re COMBOOT.COM·couldn't you just read them into hub via spin from the SD boot tracks, or better still, from a FAT16 file like I do??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (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
Post Edited (Cluso99) : 9/7/2009 8:42:20 AM GMT
Seems a bit like cheating though.
Still for now it would work a treat.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.