Not really. I can print out the disk blocks as they go through but I don't know what they relate to. Not even sure about the 32k thing either. And there is a lot of inconsistent behaviour where things are not repeatable. So lots of going back and starting with totally clean drive images. Very tedious.
I'm also trying to work out how the dma thing works. This is from the PRI in_hdskport_write | r
'#ifdef RamHDisk ????? <=============================
'read the block in from Z80 sram
r := tbp2.DoCmd("R", @disk_buff + block_offset, hdsk_dma, 128) 'Virtual "DMA" the sector from DMA buffer from SRAM
CheckError(r)
r := tbp2.idle 'give up the bus
CheckError(r)
r := sd.initSDcard(spiDO,spiClk,spiDI,spiCS) 'init the SD
CheckError(r)
' this method relies on the SD file using contiguous sectors !!! Packed 4 x 128 bytes per 512 byte sectors
err := \sd.writeSDCard(sd_block_number, @disk_buff, 512) 'write the block! (complete 512 bytes)
' CheckError(err)
So you read 128 bytes off the ram chip, but you write 512 bytes to the sd card. Where did the other 384 bytes come from? What wrote them? Where in ram is this buffer? What else can access that buffer? What is the order of reading and writing to the buffer?
Addit: Answered one of those - hdsk_dma is in spin. I have no idea what sets it
5:
hdsk_dma := io_data '5th byte is LOW of the DMA address
hdsk_command_pos++
6:
hdsk_dma := hdsk_dma + (io_data << 8) '6th (and last) byte is HIGH of the DMA address
And there is mention of the CP/M DMA (which is fixed. but this is a variable)
I guess debugging this is hard without fully understanding the code!!
There is nothing fixed about DMA in CP/M. (Well, depending on your BIOS I guess)
The boot loaders "DMA" the stuff they load dirctly to the RAM location they want it to be at finally. There is no loading to a fixed DMA buffer then copy to the final destination.
Similarly the warm boot code in CBIOSX points the DMA address at wherever it wants to load stuff.
True that when CP/M is up and running normally the CBIOS always loads (DMAs) from disk to the same sector buffer.
P.S. Blade One is up and running at 104MHz as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I started with a brand new blank drive image. (drive C)
Did a PIP of a 104k file from drive A and it worked fine
Did a PIP of the same file again and it worked fine again.
Did a PIP of a different large file (100k) and it fell over about one third of the way through and started printing rubbish on the screen.
And yet, do the same thing to drive D and it falls over on the very first PIP. Intriguingly, the rubbish on the screen was from the previous file that was PIP'ed to drive C. I think this is why I need to understand the dma buffers and where bytes are being stored. Both in spin and in CP/M.
The TriBlade board is very powerful and has many options available, which makes describing the board difficult.
However, there are two things important to the building.
1) If you build the propplug section, note the orientation of the transistor (photos on page 6 of the TriBlade thread)
2) Use the errata at the last (or next to last) page of the TriBlade thread. You must use the -OE modification to the SRAM(s) and fit the 74HC573.
There is a complete parts list at the top of the thread with part numbers from Digikey for most parts. The sram is from Future Electronics with that part number.
Each Blade circuit, the propplug section, and the I/O·may be built independantly. The recent photos show this on my new TriBlade, where I just built the power supply and partially build Blade #2. I have also built the PropPlug section but this is entirely optional.
Yesterday I added the TV (video output section) and wired it to Blade #2·P12-P14 (using the holes on the unfitted SRAM) using temporary jumpers (they are not soldered!!). The same may be done for the VGA section, Keyboard section·and Mouse section. They can all be independent sections. Care must be taken when linking these to Blade #2 to ensure no bus contention can happen. If you have any concerns, just ask.
Blade #1 is also just as powerful in a different way. As far as I know, noone is using the SRAM on this prop.
A few people have asked about R23 & R24. They are unused, uncommitted resistors just there in case we want to use them in a circuit. Therefore, do not fit them.
There are 3 uncommitted LED circuits which may be helpful in debugging and basically can be jumpered to any pin to show it's status. I use a red, a green and a blue LED.
My current TriBlade has the following fitted...· (photo a few posts back)
* Power supply·section
* PropPlug section
* Blade #2... ·· * Prop and xtal (upgraded to 6MHz yesterday -> 96MHz) (Sapeiha's running 15MHz -> 120MHz for 6 months) ·· * U23 is fitted with 512KB sram ·· * U25 is fitted with 74HC573 (could use 74LVC573) and Resistor Network RN1 ·· * J22 microSD socket ·· * U22 is fitted with 24LC512 (64KB) -·only required for·storing your program instead of downloading ·· * Do not forget the -OE modification !!! ·· * Yesterday I jumpered P12-14 to the TV section (temporary testing of video 80x25 using potatohead's code)
* TV section (Resistors 17,18, 19 and J15) and temporary jumpers to Blade #2
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
CPM uses 128 byte sectors. The hard disks are held under FAT16 on the SD (microSD) card as seperate file images (must be contiguous), one for each drive, as packed 4 x 128 byte sectors per SD sector. ZiCog takes care of the·packing/unpacking. When used, the Floppy images are held as 128 bytes per 512 byte SD sector.
refresh_hd_cache
This routine has it's own 512 byte buffer. Each time a read or write is called the cache is checked to see if it contains the current 512 byte sector in it's buffer. If so, it just returns. If not, then it will read this SD sector into the buffer and then return.
in_hdiskport_read
This routine reads a 128 byte sector as required by CPM. It calls the refresh_hd_cache routine to ensure it is in the buffer and then copies, using block mode, the whole relevant 128 byte sector to the CPM Ram. This is called DMA, but it really means it is copied in a block, rather than each byte seperately like the floppy does.
in_hdiskport_write
This routine writes a 128 byte sector as required by CPM. It calls the refresh_hd_cache routine to ensure it is in the buffer and then it copies, using block mode, the whole relevant 128 byte sector from the CPM Ram. This is called DMA. Then, the whole 512 byte sector is written back to the SD card.
If there are any questions, please ask
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have spent a couple of hours studying the dma code and how the buffers work. I can see how this works and it all seems to make sense and I have thought of all sorts of read/write/read scenarios and can't think of any way that incorrect data could get through. writesd is only called once for hard drive routines (and once in the floppy routines), and before this refresh_hd_cache is called so the cache is always updated
So - earlier you mentioned something about one of the bootup bits of code. This is a block of data that I think either you or heater created, so it is a bit hard to debug.
Drac: Our posts crossed, so please see description of the code, although I think you understand it anyway.
Yes, it is up to heater to find the solution. Heater, perhaps you could create say a 40KB version, to see if the problem is still there? The 64KB floppy version works.
Potatohead: Nice to see you here
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
For those who are following and still want to play while we find/fix the 64K/PIP bug, here is _rr123 which has 2 floppies A & B and 2 hard drives I & J.
Attached are 3 files
Source code
Binary code (compiled for 5MHz xtal). You can use PropTool to download it.
SD files required
DSKBOOT_.ROM·· (boots CPM) unchanged from previous releases
DRVCPM_2.DSK··· (A: floppy file for CPM2.2)
DRVCPM_3.DSK··· (B: floppy file for CPM3)
BLANK_I0.DSK····· (I:·Hard disk file - blank)
BLANK_J0.DSK····· (J: Hard disk file - blank)
BLANK_E5.DSK····· (unused, just a blank hard disk)
Postedit: This is a working 64KB CPM2.2 version with 2 Floppies and 2 8MB hard drives.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Maybe I'm a bit tired.
I'm looking at SramTest1MB.spin and all I can see is that it tests 1024 bytes (from U23 according to the comments)
Should ReadRam and WriteRam be using ram_enable_lo instead of ram_enable_hi ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I want to do a RAM test because, well, I've always been fastidious about testing even the smallest sub assemblies before jumping to the big construction and ending up head scratching when nothing works at the end of it. Comes from a bad experience building my Nixie tube and TTL clock on my own design home etched PCB in 1973 [noparse]:)[/noparse]
But more importantly in this case I don't have an SD card attached. So firing up TriBlade for external RAM is not going to do very much.
I have no SD card socket so I will have to hang an SD card onto the board as best I can, which may not be very good. I'd like to know the RAM works before moving on to that step (and again after it).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hanging the sd off the board would be fine. I'm hanging a seperate max232 board off my board (half a picaxe interface circuit). Lots of hot melt glue to reinforce the connections. Got to get you triblading, heater!
Woot! There is so much code working behind that little signon message. Fantastic to see.
Are you at the point of being able to replicate the 'big file bug'?
There are several ways to replicate it - eg with Wordstar (but this prints escape characters all over a non VT100 terminal, so it is hard to see the bug) and BDS C. But perhaps the easiest is to put a large (40k?) text file on one hard drive and try doing a PIP to another hard drive.
Of course, if you can't replicate it, that would be even more exciting!
Now worries if this version works [noparse]:)[/noparse]
I'm planning on starting from this stock SIMH BIOS and gradually morphing it step by step into the one we want. Hopefully finding the problem at one of the steps.
This is what I did originally, carefully checking that each step worked as expected. Which it did, in 25K RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A>ls b:
0 File(s), occupying 0K of 8136K total capacity
1024 directory entries and 8136K bytes remain on B:
A>boot
64K CP/M Version 2.2 (ZiCog, BIOS V1.27_Zi04, 8 HD, 10-Sep-2009)
A>ls bdos.prn
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
BDOS PRN 168K
1 File(s), occupying 168K of 8136K total capacity
948 directory entries and 7272K bytes remain on A:
A>pip b:=bdos.prn
A>ls b:
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
BDOS PRN 168K
1 File(s), occupying 168K of 8136K total capacity
1018 directory entries and 7968K bytes remain on B:
A>
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Looking good! Are you using different code? There are a few more tests to do as occasionally I did manage to get a big file over onto a clean drive - next test might be to erase that file, then copy another big file over with a different name. If that works, then do a PIP *.* of one of the simh disks.
Sorry to be so mysterious. I have to do a lot more testing here as you say. Just now I've managed to do a few sessions of:
ERA B:*.*
PIP B:=A:*.*
TYPE B:BDOS.PRN
etc. etc.
I have yet to see a crash.
Same code just configured slightly differently. I won't be happy until I find out exactly what this is about.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
I'm also trying to work out how the dma thing works. This is from the PRI in_hdskport_write | r
'#ifdef RamHDisk ????? <============================= 'read the block in from Z80 sram r := tbp2.DoCmd("R", @disk_buff + block_offset, hdsk_dma, 128) 'Virtual "DMA" the sector from DMA buffer from SRAM CheckError(r) r := tbp2.idle 'give up the bus CheckError(r) r := sd.initSDcard(spiDO,spiClk,spiDI,spiCS) 'init the SD CheckError(r) ' this method relies on the SD file using contiguous sectors !!! Packed 4 x 128 bytes per 512 byte sectors err := \sd.writeSDCard(sd_block_number, @disk_buff, 512) 'write the block! (complete 512 bytes) ' CheckError(err)So you read 128 bytes off the ram chip, but you write 512 bytes to the sd card. Where did the other 384 bytes come from? What wrote them? Where in ram is this buffer? What else can access that buffer? What is the order of reading and writing to the buffer?
Addit: Answered one of those - hdsk_dma is in spin. I have no idea what sets it
5:
hdsk_dma := io_data '5th byte is LOW of the DMA address
hdsk_command_pos++
6:
hdsk_dma := hdsk_dma + (io_data << 8) '6th (and last) byte is HIGH of the DMA address
And there is mention of the CP/M DMA (which is fixed. but this is a variable)
I guess debugging this is hard without fully understanding the code!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/22/2009 12:23:02 PM GMT
The boot loaders "DMA" the stuff they load dirctly to the RAM location they want it to be at finally. There is no loading to a fixed DMA buffer then copy to the final destination.
Similarly the warm boot code in CBIOSX points the DMA address at wherever it wants to load stuff.
True that when CP/M is up and running normally the CBIOS always loads (DMAs) from disk to the same sector buffer.
P.S. Blade One is up and running at 104MHz as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I started with a brand new blank drive image. (drive C)
Did a PIP of a 104k file from drive A and it worked fine
Did a PIP of the same file again and it worked fine again.
Did a PIP of a different large file (100k) and it fell over about one third of the way through and started printing rubbish on the screen.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
What's the latest/best RAM test to use prior to attempting to run ZiCog ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The TriBlade board is very powerful and has many options available, which makes describing the board difficult.
However, there are two things important to the building.
1) If you build the propplug section, note the orientation of the transistor (photos on page 6 of the TriBlade thread)
2) Use the errata at the last (or next to last) page of the TriBlade thread. You must use the -OE modification to the SRAM(s) and fit the 74HC573.
There is a complete parts list at the top of the thread with part numbers from Digikey for most parts. The sram is from Future Electronics with that part number.
Each Blade circuit, the propplug section, and the I/O·may be built independantly. The recent photos show this on my new TriBlade, where I just built the power supply and partially build Blade #2. I have also built the PropPlug section but this is entirely optional.
Yesterday I added the TV (video output section) and wired it to Blade #2·P12-P14 (using the holes on the unfitted SRAM) using temporary jumpers (they are not soldered!!). The same may be done for the VGA section, Keyboard section·and Mouse section. They can all be independent sections. Care must be taken when linking these to Blade #2 to ensure no bus contention can happen. If you have any concerns, just ask.
Blade #1 is also just as powerful in a different way. As far as I know, noone is using the SRAM on this prop.
A few people have asked about R23 & R24. They are unused, uncommitted resistors just there in case we want to use them in a circuit. Therefore, do not fit them.
There are 3 uncommitted LED circuits which may be helpful in debugging and basically can be jumpered to any pin to show it's status. I use a red, a green and a blue LED.
My current TriBlade has the following fitted...· (photo a few posts back)
* Power supply·section
* PropPlug section
* Blade #2...
·· * Prop and xtal (upgraded to 6MHz yesterday -> 96MHz) (Sapeiha's running 15MHz -> 120MHz for 6 months)
·· * U23 is fitted with 512KB sram
·· * U25 is fitted with 74HC573 (could use 74LVC573) and Resistor Network RN1
·· * J22 microSD socket
·· * U22 is fitted with 24LC512 (64KB) -·only required for·storing your program instead of downloading
·· * Do not forget the -OE modification !!!
·· * Yesterday I jumpered P12-14 to the TV section (temporary testing of video 80x25 using potatohead's code)
* TV section (Resistors 17,18, 19 and J15) and temporary jumpers to Blade #2
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Drac: I will explain the dma shortly but I think you are looking at a commented out section.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Color is coming soon. Man, I kind of want to build one of these!
(soon...)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
CPM uses 128 byte sectors. The hard disks are held under FAT16 on the SD (microSD) card as seperate file images (must be contiguous), one for each drive, as packed 4 x 128 byte sectors per SD sector. ZiCog takes care of the·packing/unpacking. When used, the Floppy images are held as 128 bytes per 512 byte SD sector.
refresh_hd_cache
This routine has it's own 512 byte buffer. Each time a read or write is called the cache is checked to see if it contains the current 512 byte sector in it's buffer. If so, it just returns. If not, then it will read this SD sector into the buffer and then return.
in_hdiskport_read
This routine reads a 128 byte sector as required by CPM. It calls the refresh_hd_cache routine to ensure it is in the buffer and then copies, using block mode, the whole relevant 128 byte sector to the CPM Ram. This is called DMA, but it really means it is copied in a block, rather than each byte seperately like the floppy does.
in_hdiskport_write
This routine writes a 128 byte sector as required by CPM. It calls the refresh_hd_cache routine to ensure it is in the buffer and then it copies, using block mode, the whole relevant 128 byte sector from the CPM Ram. This is called DMA. Then, the whole 512 byte sector is written back to the SD card.
If there are any questions, please ask
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 spent a couple of hours studying the dma code and how the buffers work. I can see how this works and it all seems to make sense and I have thought of all sorts of read/write/read scenarios and can't think of any way that incorrect data could get through. writesd is only called once for hard drive routines (and once in the floppy routines), and before this refresh_hd_cache is called so the cache is always updated
So - earlier you mentioned something about one of the bootup bits of code. This is a block of data that I think either you or heater created, so it is a bit hard to debug.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Yes, it is up to heater to find the solution. Heater, perhaps you could create say a 40KB version, to see if the problem is still there? The 64KB floppy version works.
Potatohead: Nice to see you here
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Currently on Blade 2 I have fitted only: the Prop, RAM as U23, EEPROM, latch, resistor network and all other Cs and Rs. Crystal is 6.5536MHz
I have made the OE mod. U23 pin 24 disconnected from the board and then linked to U21 pin 37.
I do not have an SD card attached (or even the socket)
Power comes from the Blade 1 PSU.
I can program RAM and EEPROM with a Prop Plug via J21 and 25K ZiCog does at least start up such that I can single step through the ZIBOOT code.
SramTest1MB.spin fails.
When I have a moment I will buzz this out and check all connections shorts etc.
Is there a net list I could use as a check list? Working from the schematic makes my eyes spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Attached are 3 files
Postedit: This is a working 64KB CPM2.2 version with 2 Floppies and 2 8MB hard drives.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/27/2009 3:28:31 AM GMT
I'm looking at SramTest1MB.spin and all I can see is that it tests 1024 bytes (from U23 according to the comments)
Should ReadRam and WriteRam be using ram_enable_lo instead of ram_enable_hi ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
But more importantly in this case I don't have an SD card attached. So firing up TriBlade for external RAM is not going to do very much.
I have no SD card socket so I will have to hang an SD card onto the board as best I can, which may not be very good. I'd like to know the RAM works before moving on to that step (and again after it).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Cannot get to my dev laptop and the moment - wife playing solitaire
Heater: re microSD
If you can get an SD to microSD adapter (readily available) solder the·pins via wires·as follows.... (use the U25 Flash pins for all but 1 pin)
http://www.dd-wrt.com/wiki/index.php/Linksys_WRT54G-TM_SD/MMC_mod
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/23/2009 8:36:42 AM GMT
Just started another stint of real work so this will have to wait until much later today[noparse]:([/noparse]
I'm all set with SD adapters. That's pretty much what I had in mind and what I have on my Prop Demo board.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Every location is tested, but each only with one value which is incrementing in each successive location, so it should catch any shorts or opens.
I noticed that the TriBlade #2 driver is not working above 512KB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Are you at the point of being able to replicate the 'big file bug'?
There are several ways to replicate it - eg with Wordstar (but this prints escape characters all over a non VT100 terminal, so it is hard to see the bug) and BDS C. But perhaps the easiest is to put a large (40k?) text file on one hard drive and try doing a PIP to another hard drive.
Of course, if you can't replicate it, that would be even more exciting!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I'm planning on starting from this stock SIMH BIOS and gradually morphing it step by step into the one we want. Hopefully finding the problem at one of the steps.
This is what I did originally, carefully checking that each step worked as expected. Which it did, in 25K RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
ERA B:*.*
PIP B:=A:*.*
TYPE B:BDOS.PRN
etc. etc.
I have yet to see a crash.
Same code just configured slightly differently. I won't be happy until I find out exactly what this is about.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.