 |
|
 |
| Parallax Forums > Public Forums > Propeller Chip > TriBladeProp PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC) | Forum Quick Jump
|
 | 
Dr_Acula
Registered Member
      
Date Joined Dec 2008
Total Posts : 606
| Posted 8/30/2009 4:00 PM (GMT -8) |   | Cluso - yes I'll have a look at the bst terminal. I've been doing things that need VT100 terminal codes (eg wordstar) and also xmodem for file downloads. Teraterm, hyperterminal and my vb.net terminal program can both do VT100 and xmodem. Can the bst terminal do those as well?
Re heaters ponderings, the one thing I'd like to see is a bit more speed. For instance, when you are in a drive and you change to another drive, it takes a long time to change drives. Ditto when you are in mbasic or wordstar and return to the system. I think both processes involve a 'warm boot'. A warm boot involves reloading cp/m off the disk and the disks are the sd disks which are slow. I added a switch some months ago to the N8VEM where you could bypass reloading cp/m on a warm boot and it seems to work fine. There are a handful of programs that overwrite cp/m but not the ones I use so a reload of cp/m is not needed.
And as a general question, are the sd card reads now as fast as they can possibly be?
However, I just thought of a cunning plan. Now that cluso has very cleverly added drive J, the ramdrive, would it be possible on bootup to move the bootloader code over to drive J, say on the 'boot tracks' of the ram drive. Then subsequent warm boots would load off the ram drive and it would be much faster changing drives etc.
Or bypass the warm boot code? But that moves away from simh compatability. I know there is a circular argument regarding that, but one aim of any software ought to be to make it user friendly and if it becomes more hardware specific then it can be re-posted as a simh variant.
re a hub memory only version, how much hub ram is free now? I'm pondering crazy ideas like loading in an 8k block of data from the sram chip into hub memory as part of the zicog simulation, and then as the program jumps around it probably will be in that block of code and then you don't have to read the instructions from sram each time. ? would it give a speedup Is there enough hub ram free? Addit no, scratch that idea - it would work for a self contained program but not so good if the program called cp/m bdos calls a lot as these parts of code are at either ends of the 64k ram space.
So - back to reality...
Are we ready to move to CPM3 and MPM? A big project, but it would be really cool to see multitasking running.Post Edited (Dr_Acula) : 8/31/2009 12:20:56 AM GMT | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 8/30/2009 4:19 PM (GMT -8) | | | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 8/30/2009 4:38 PM (GMT -8) | | Thanks for the postedit cluso - I was a bit confused there as you said yes but no in the wear issues etc.
So ok, keep the 32mb drives?
I'm not sure it makes much difference to speed anyway.
Can I just clarify, when you read a sector, does the sd card code send heaps of pulses first to somehow reset the card? | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 8/30/2009 5:32 PM (GMT -8) | | Ah, ok. And I know we have covered this before and I know it is on the (ever growing) list of things to do. I guess the reason it is relevant is that there may not be much point packing the drives down from 32 to 8mb for a small speed gain if there is going to be a much bigger gain down the track from different sd card code.
The code to expand the drives is pretty simple to use (either the vb6 code or some simple python). I might integrate it into the N8VEM vb.net ide as well. Indeed, one of the things the vb.net ide can do is to batch downloading of many files via xmodem. eg the wordstar package. So I've got drive A as the cp/m drive and then I'm just dropping in lots of blank drives at the moment and then set the ide going sending over wordstar via xmodem. For just a few files it is quicker than firing up the simh, reading in files, then expanding out the drive image and removing the sd card and copying it across and then putting the card back in again and then doing a reboot.
I'm now trying to get my head around the simultaneous discussion on the N8VEM forum about trying to create common file images. Hard or floppy drive images? 8 or 32mb? Boot from drive or boot from eprom? Boot from floppy drive or hard drive? I'm not sure of any answers yet. Just trying to understand the questions first! | | Back to Top | | |
|
Cluso99
We live onboard
Date Joined Apr 2008
Total Posts : 2276
| Posted 8/30/2009 6:03 PM (GMT -8) | | The boot from floppy is REAL SIMPLE now. Heater is convinced it is as easy to boot from a hard drive, but we need to get the hdp working. And as you can see from the spin demo code, it is easy to boot from different drives to run CPM2, CPM3 or indeed MPM.
The first objective is to use common file formats for N8VEM (and PropIO) and the Prop versions of ZiCog. I would say this is done from our side - 1x128 per 512 SD sector for now, maybe 4x128 per 512 SD sector at a later date.
Ultimately, I am sure we will boot the whole project from SD card because we can then boot PropDos, MoCog, etc. I have actually done this some months ago. However, the boot code can simply be a file on the SD card under FAT16 and just this file could be different for N8VEM booting meaning a standard EPROM bootloader and no more EPROM burning for the N8VEM group 
Anyway, just working on getting the new SD driver running. There are interdependencies between the pasm driver and the spin above it that I need to work through because I have to add a function to tristate the SD pins and reenable them as they are shared between the SD card and the SRAM bus, and it will remain that way for speed on my cards anyway.
Links to other interesting threads:
| | Back to Top | | |
|
Yoda
Registered Member
Date Joined Mar 2009
Total Posts : 61
| Posted 8/30/2009 7:38 PM (GMT -8) | | Cluso
I plan to do the packing / unpacking on the propeller side. I don't understand the wear issue, you actually do less I/O at least on the read side and come close to even on the write side. There is no delayed write in the way I am implementing. In some cases I may have to do a read modify write but if doing sequential write I would only have to do that on every fourth right. On the read side there in general will be a quarter of the reads with packed versus upacked.
I am still in favor of packed drives. Sorry my real job got in the way this week and have not done much but am hoping to get a lot done this week I hope. Next weekend in holiday weekend in the US so maybe I can get a lot more done.
Dave | | Back to Top | | |
|
heater
Registered Member
Date Joined Feb 2008
Total Posts : 1832
| Posted 8/30/2009 10:26 PM (GMT -8) | | Dr_A:
The need for speed -- Yes we need more. I love the N8VEM for its instant start up. We may never get to that but:
1) Booting from hard disks will be much faster. I want to dump all support for those slow Altair floppies in the emulator and in the CBIOSX. Boot from RAM disk probably does not help initial boot as it has to be loaded from SD anyway (unless we get battery backed RAM) BUT warm boots would then be much faster !
Lets not worry about the HUB RAM only "demo" version, we have pushed it as far as is reasonable.
CP/M 3 has already been working on TriBlade. If we dump Altair disks it will need the same BIOS mods as proposed for CP/M 2 CBISOX, and the same again for MP/M.
Cluso:
Enough said about DMA already:) We both know how it works in reality, as far as I'm concerned the Z80 sees DMA, the spin code sees a block move. Who cares what we call it we know what we mean. Except - I have never said anything about a another COG doing DMA. It's impossible as you say and I'm quite happy with what we have done there.
Looking forward to the faster SD driver.
Yoda:
Yes, packing/unpacking (blocking/unblocking) should happen in the Prop side. If the Z80 does it we have a slow down especially for the emulation.
I have implemented 4 * 128 byte sectors in 512 byte SD blocks for floppy and HD emulation. It works fine. Given that CP/M uses alocation blocks on disk of 1K, 2K or whatever then there is a lot of sequential access going on. So there should be a 4 fold increase in read speed. There is no wear issue with reads.
Currently I don't do delayed writes, the SD block buffer is updated and written for each CP/M sector. This is the safest way to do it but, as Cluso points out, means that each SD block gets 4 times more writes than if we just used one CP/M sector per SD block.
Cluso:
Don't worry about the real Z80 wanting 512 bye sectors. If it does that is a bug that should be fixed as everyone agrees that packing/unpackingshould happen in the Prop side.
Implementing delayed writes for "packed" sectors/blocks would be a risky proposition as you say. I agree that having an "interrupt" to the Z80 or a time check in the opcode cycle is not a good idea. The only way I could think to time out the delayed writes is during the time the CBIOS is polling the console port. This would not slow or complicate the actual Z80 emulation. But seems a very risky idea regarding possible data loss/disk corruption. What happens if the program does not want to read fronm the console? I think delayed writes are a no-no.
So packed sectors gives:
1) Smaller images
2) Faster reads, boot times
3) A little bit slower writes, due to prefetching SD blocks. Remember most access are sequential to 1K or 2K so only one block needs fetching for every 4 sector writes.
Down side is:
1) 4 times more wear on a sector.
The wear issue will not concern me until I see it:) Are we really going to hammer the SD so much? Is the wear leveling in the SD card itself not good enough? I don't know.
Have at look at that last zicog_demo.spin I put up. The code for packed sectors is not at all complex.
I'd be quite happy to adopt packed sectors but am prepared to sit on it for now.
Instead, I will get on with CBIOS mods, Altair floppy disk removal, booting from HD, getting floppy format disks into the HD driver.
For me, the past is not over yet. | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 8/31/2009 3:05 AM (GMT -8) | | Re "Or even more radical, why bother with 1M floppies at all ?"
Well, the problem here and now on my zicog is that it can't boot to a hard drive image. So if you can't boot off a drive, you can't run anything.
UNLESS.... you have got it to boot off a hard drive image???
And if that is possible, then yes, why have floppy images. | | Back to Top | | |
|
heater
Registered Member
Date Joined Feb 2008
Total Posts : 1832
| Posted 8/31/2009 4:40 AM (GMT -8) | | OK I now have a CBIOSX with no Altair floppy driver support.
Drives A: B: and C: are all 8Mb
As I have packed sectors enabled the image on SD card is exactly that of a SIMH I.DSK with no pre-processing !!!
Does it start up faster?
Oh yes it does and it would be quicker still if these were floppy geometry disks with 256 directory entries to scan instead of 1024.
Any way, just proves the point that we don't need the Altair driver.
ZiCog v0.10 on the Prop Demo Board
Starting disks (A:B:C:) ...
Passed, please wait...
RAM base = 00E8
ROM base = 58E8
Starting Z80 emulation...
Passed, please wait...
24K CP/M Version 2.2 (ZiCog, BIOS V1.27_Z01, 3 HD, 31-Aug-2009)
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:
0 File(s), occupying 0K of 8136K total capacity
1024 directory entries and 8136K bytes remain on B:hdsk param
A>ls c:
0 File(s), occupying 0K of 8136K total capacity
For me, the past is not over yet. | | Back to Top | | |
|
Dr_Acula
Registered Member
Date Joined Dec 2008
Total Posts : 606
| Posted 8/31/2009 5:14 AM (GMT -8) | | Boot up times in this configuration: Less than 1 second. Feels closer to 0.5s.
What, from switch on to the A>?? No way!
Just now I want to prove that we can do any/many of these options.
Yes maybe that is the way forward. Do as many as possible and let the 'marketplace' decide.
I suspect the fastest large drive will be the most popular. But I still see a place for the simplicity of copying a straight simh disk.
I still don't understand the bootloader. It loads the sram with this code
'read the DSKBOOT_.ROM file (256 bytes)
r := sd.initSDCard(spiDO,spiClk,spiDI,spiCS) 'init SD card, but do not restart cog
CheckError(r)
r := sd.readSDCard(drive_base[16], @buff, 256) 'get 256 bytes
CheckError(r)
r := sd.stopSDCard 'stop SD card, but do not stop cog
CheckError(r)
'copy the 256 bytes to $FF00-$FFFF in sram
r := tbp2.active 'activate the bus
CheckError(r)
r := tbp2.DoCmd("W", @buff, $FF00, 256) 'write to sram
CheckError(r)
'now set the buffer to "$E5" and fill the remainder of sram for use as empty RamDisk
repeat i from 0 to count - 1 'set 8KB block = $E5
buff[ i ] := $E5
repeat i from b1 to b2 - 1 '8 to 63/127: write 56/120 x 8KB blocks of sram above first 64KB
r := tbp2.DoCmd("W", @buff, i * count, count) 'write to sram
CheckError(r)
and then jumps straight into the zicog. Does it then got and read off the boot tracks off of drive A?
Addit - checking out those .mac files
; The sectors of a track are read in the following order:
; first even sectors, then odd sectors in ascending order
; 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,
; 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31
All credit to you heater for decoding this as I tried looking at the boot sectors of a hard disk image with a binary file viewer and the data didn't seem to bear any resemblence to the order above. If you have cracked the code =>kudos.Post Edited (Dr_Acula) : 8/31/2009 1:26:28 PM GMT | | Back to Top | | |
| 849 posts in this thread.
Viewing Page : |
| Forum Information | Currently it is Friday, November 20, 2009 11:27 PM (GMT -8)
There are a total of 393,739 posts in 55,521 threads.
In the last 3 days there were 81 new threads and 701 reply posts. View Active Threads
| | Who's Online | This forum has 17687 registered members. Please welcome our newest member, mark09.
51 Guest(s), 5 Registered Member(s) are currently online. Details
StefanL38, Dr_Acula, W9GFO, pharseid, micromang |
Forum powered by dotNetBB v2.42EC SP2.02
dotNetBB © 2000-2009 |
|
|