Dr_Acula said...
Re "Do you run all the nops from 0000 until you hit the ROM at ff00? It seems so..."
Ah, that was actually the code you were helping me with a couple of days ago. Poke 3 bytes at location 0,1,2 and those three bytes are C3, 00 and FF.
So the steps for startup on the dracblade are:
' Initialise serial ports, keyboard, vga screen' Find the location of all the hard drives on the sd card and store the location of each
FindSDblock
' Poke C3, 00 FF to ram 0,1,2 long[noparse][[/noparse]buffcog]:=$00FF00C3' and then
RamLatches.DoCmd("W", buffcog, 0, 3) ' write 3 bytes in buffcog to address 0' Load BOOT.DSK into the buffer
r := sd.readSDCard(drive_base[noparse][[/noparse]17], buffcog, 256) 'get 256 bytes "BOOTxxxx.ROM"
r := RamLatches.DoCmd("W", buffcog, $FF00, 256) 'write 256 bytes from buff to sram
and then start the zicog.
Ah, I see, that was what you patched. I implemented some dummy functions in io.spin for the SIMH commands and hard disk commands that the boot ROM expects. I suppose you use an I/O handler which deals with the SD cards and external memory!? I have an SD card and some USB adapter, which I don't really need. I could wire it to my board... oh, that card slot has more than 4 pins.
1 CS
2 DI
3 GND
4 VCC (3.3V)
5 SCK
6 GND1
7 DO
8 IRQ
9 ???
10+11 ?? (two pins that are very close together)
Anyone knows if I have to care about the pins 9-11? It looks like pin 9 is connected to the SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/13/2010 12:25:38 AM GMT
How log before one of you manages to compress everything into one self extracting long?
Huh? That long would probably have a value of 42.
No, actually it came to me that I was stupid to store the opcode flags inside the table. Now I store the flags in the longs that have the length of each code snippet, and that way I could change the tables to words. That got me 4*128 longs more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Scroll down to nearly the bottom of that page to this paragraph
"Eagle files here as well as a schematic in pdf. The parts list is available here Full package of the propeller files, disk images and a terminal program here as a zip file."
and click on the schematic. Zoom into the sd card bit. Pins 9,10,11 don't matter, just leave them unconnected. SD cards are really 4 pins though there are 8 pins to connect. Gnd twice. 3V3. Pullup on pin 8. and that leaves the 4 pins DO, DI, CS and CLK
I have a vague feeling one of the other lines doesn't matter either, but I left out one pullup on one of my board designs and it stopped working so that is the schematic I am sticking with.
I/O handler for sd card etc? Yes, any I/O gets trapped in a simple spin routine
'------------------------------------------------------------------------------' Service I/O'------------------------------------------------------------------------------
PRI service_io | d ' d=delay'Altair I/O simulation service loop'I/O control block commands'io_cmd_out = $01'io_cmd_in = $02'io_cmd_break = $03
repeat
CheckCountdown1 ' sd card timeout
CheckCountdown2 ' vga blank timeout
TestPort2 ' eg #ALP or #BET, #OFF, #WHO #BYE'vgatext.str(string("serviceio"))
repeat 250' spend most of the time checking i/o don't make this too high otherwise the screensaver doesn't work (not sure why, must be something in the subtraction math)case io_command
io_cmd_break: ' 03
on_break ' Break (for single stepping)
io_cmd_in: ' 02
on_input 'An input operation
io_cmd_out: ' 01
on_output 'An output operation
Let's say it matches with "on_output" it will jump here:
PRIon_output'Handle Z80 IO port writes'simhport = $FE'hdskport = $fd ' control port for simulated hard disk case io_port
' ledport: 'An 8 bit parallel output with LEDs attached' out_ledport
simhport: 'SIMH control port $FE' out_simhport
condata: 'Console data port
out_condata
constat: 'Console status port' out_constat
punstat:
' out_punstat 'Punch control port
n8vem_uart_out: '&H68
out_n8vem_byte
port2_io: ' for output to port 2
out_port2
port2_baud: ' set baud rate for port 2
baud_port2
Forecolor: ' set the foreground color RRGGBB00
set_forecolor
Backcolor: ' set background color RRGGBB00
set_backcolor
hdskport: ' $FD
out_hdskport 'SIMH style hard disk port
myname_port: ' port &H70
GetMyname ' returns board name in DMA 80H'Port2_Off: ' port &H71' Port2_Disconnect ' disconnect port 2 control' ram: ' write a byte to ram (port $76)' poke_ram ' commented out as not used and takes up spin code spaceother:
PrintStringCR(string("Er8"))
' UART.hex(0,io_port,2) 'print the port number for debugging
io_command := 0'Set flag ready for next io
Serial port I/O is pretty straightforward from here, but say you are sending to a disk, it would jump to out_hdskport
PRI out_hdskport
'Handle writes to the SIMH style hard disk port'Handling is dispatched to an apropriate function depending'on the command currently in progress.'FIXME: RESET should be checked on every write no matter the command in progress.'hdskNull = 0 ' No command'hdskReset = 1 ' command to reset controller'hdskRead = 2 ' read command'hdskWrite = 3 ' write command'hdskParam = 4 ' Get HD parameters command' can't put diag messages in a case command, only at the beginningcase hdsk_current_command
hdskRead:
hdsk_get_rw_params
hdskWrite:
hdsk_get_rw_params
hdskParam:
out_hdskport_param
hdskReset:
PrintStringCR(string("Er12"))
repeat
hdskNull:
out_hdskport_null
other:
PrintStringCR(string("Er13"))
repeat
and now I have posted about half the code!
So maybe take a peek at the attachment especially the Main_Dr_Acula.spin
I already had your schematics. I looked at the v5 sheet.
Dr_Acula said...
Pins 9,10,11 don't matter, just leave them unconnected. SD cards are really 4 pins though there are 8 pins to connect. Gnd twice. 3V3. Pullup on pin 8. and that leaves the 4 pins DO, DI, CS and CLK
Ok, so I have to find some 10k resistors for the lines that go to the prop. Finally found 5... done.
Dr_Acula said...
I/O handler for sd card etc? Yes, any I/O gets trapped in a simple spin routine
Ah, ok. I'll use that as a reference for my io.spin, which is in PASM.
Dr_Acula said...
So maybe take a peek at the attachment especially the Main_Dr_Acula.spin
Yep, will do after I got the SD card working.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Just to warn you that the make of the SD card seems to be vital. Sandisk ones have been good, the two (full sized) that work for me are "Integral" but a couple of other cards will format and load, as expected, but will not work on the Prop. Others have had this problem, on other Prop projects too.
Format them with FAT, NOT FAT32, and dump ovet the files straight away to get contiguous sectors. The drivers are very tolerant of pin location, I shifted mine over to P20-23, having restricted the VGA to four pins P16-19, with no problems. The 10K resistors do not seem to be vital but I do usually fit them, even if it is only on the /CS line.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 3/13/2010 8:34:53 AM GMT
Just to warn you that the make of the SD card seems to be vital. Sandisk ones have been good, the two (full sized) that work for me are "Integral" but a couple of other cards will format and load, as expected, but will not work on the Prop. Others have had this problem, on other Prop projects too.
Format them with FAT, NOT FAT32, and dump ovet the files straight away to get contiguous sectors. The drivers are very tolerant of pin location, I shifted mine over to P20-23, having restricted the VGA to four pins P16-19, with no problems. The 10K resistors do not seem to be vital but I do usually fit them, even if it is only on the /CS line.
Well, I currently have just one 4GB Entryx SD card here. I'll play around with the sdspiFemto.spin to see if/how I can read from the card.
Formatting it is not a problem. I wonder why noone has written a tool to just put the required images in fixed places? You don't need a file system for how this CP/M system uses the SD cards. That could save some space on the Prop if you threw out fsrwFemto.spin. After all you don't want to modify files on the FAT(32) fs, but just write inside the images...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Toby Seckshund said...
Back in the early days the files were put onto the card, and the the start of the block was found, and the worked on.
Those days left me floundering on how to start. As soon as the FAT way was introduced it was much more obvious.
Well, but it would save a lot of hub RAM if there was no fsrwFemto.spin required to access the images on the SD card.
It should be possible to write a tool that just copies the expected file images to a card on the PC.
On *nix this could even be a shell script.
Toby Seckshund said...
Only the first 2G will be seen by the SPI mode, fingers crossed that it is a friendly card.
Nope, it is not. The fs.mount fails. I double checked my pins and they should be ok. I attached the card slot to pins 8,9,10,11 (DO,Clk,DI,CS), because 12,13,14,15 are actually the TV output.
Meanwhile I found a couple of cut+paste bugs in the Z80 core. It now runs my own instruction tester ok - it still fails to run the EXZ80DOC.COM :-/ The only way to nail this infamous last bug(TM) will be to cycle through all instructions and look at the expected result and flags.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
pullmoll: For a long time ZiCog and PropAltair before it did not use FAT on the SD card, only direct block access as requested by CP/M. I too thought FAT was totally redundant after all CP/M is a perfectly good operating system and has its own file system and that is the point of this whole exercise.
Eventually I had to give in to popular demand and include FAT and image files. Windows users just don't have the luxury of dd.
Actually, Dr_A if you want to save a ton of HUB space in your DracBlades just ditch FAT and write CP/M disks directly to the SD card as God intended. After all FAT is sitting there doing nothing once CP/M is running. Just wasting precious space.
Recently I found a Windows tool that did for SD cards what dd does for Linux users. Damned if I can remember what it was called now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
pullmoll: For a long time ZiCog and PropAltair before it did not use FAT on the SD card, only direct block access as requested by CP/M. I too thought FAT was totally redundant after all CP/M is a perfectly good operating system and has its own file system and that is the point of this whole exercise.
Eventually I had to give in to popular demand and include FAT and image files. Windows users just don't have the luxury of dd.
Actually, Dr_A if you want to save a ton of HUB space in your DracBlades just ditch FAT and write CP/M disks directly to the SD card as God intended. After all FAT is sitting there doing nothing once CP/M is running. Just wasting precious space.
Recently I found a Windows tool that did for SD cards what dd does for Linux users. Damned if I can remember what it was called now.
Nah, come on, you can just open the device with \\<device id> somehow, just as well as you can open harddisks. Then all that's left to do is some file reading and seeking + writing on the raw image handle. If all else fails, I could try to whip up a nice and user friendly (read: colorful and clickable) Windows app to do that, including a setup that asks you 7 times to click on Next Mac OSX users should have a dd.
BTW while looking at Dr_Acula's code collection, specificially the main, my eyes started bleeding This code could use some severe cleanup anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Pullmoll: Let me, let me. This FAT thing has been bugging me for a long time. Why spend all this effort getting CP/M up and running on the Prop just to have this MicroSoft boat anchor tied around it? It's totally disrespectful to Digital Research and Gary Kildall.
My plan is to create a cross platform disk sector writer using Qt.
I have never tried accessing sectors directly in Windows but it looks like it might me as simple as this.
// win NT/2K/XP code
HANDLE hDevice;
DWORD bytesread;
char _devicename[noparse][[/noparse]] = "\\\\.\\A:";
_devicename += drive;
// Creating a handle to disk drive using CreateFile () function ..
hDevice = CreateFile(_devicename,
GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL, OPEN_EXISTING, 0, NULL);
if (hDevice == INVALID_HANDLE_VALUE)
returnNULL;
// Setting the pointer to point to the start of the sector we want to read ..
SetFilePointer (hDevice, (startinglogicalsector*512), NULL, FILE_BEGIN);
if (!ReadFile (hDevice, buffer, 512*numberofsectors, &bytesread, NULL) )
returnNULL;
}
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Pullmoll: Let me, let me. This FAT thing has been bugging me for a long time. Why spend all this effort getting CP/M up and running on the Prop just to have this MicroSoft boat anchor tied around it? It's totally disrespectful to Digital Research and Gary Kildall.
My plan is to create a cross platform disk sector writer using Qt.
I have never tried accessing sectors directly in Windows but it looks like it might me as simple as this.
// win NT/2K/XP code
HANDLE hDevice;
DWORD bytesread;
char _devicename[noparse][[/noparse]] = "\\\\.\\A:";
_devicename += drive;
// Creating a handle to disk drive using CreateFile () function ..
hDevice = CreateFile(_devicename,
GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL, OPEN_EXISTING, 0, NULL);
if (hDevice == INVALID_HANDLE_VALUE)
returnNULL;
// Setting the pointer to point to the start of the sector we want to read ..
SetFilePointer (hDevice, (startinglogicalsector*512), NULL, FILE_BEGIN);
if (!ReadFile (hDevice, buffer, 512*numberofsectors, &bytesread, NULL) )
returnNULL;
}
It is as simple as this.. well, if you really want to call CreateFile() parameters simple. I have once tried to understand them all... Anyway, enough M$ bashing, please do it! I will buy me a SanDisk 2GB and use the same layout that you decide upon. I think the BOOTDSK_.ROM file will be the first? Then, perhaps aligned, just the 8M hard disk images?!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
The good thing that the anchor may have brought is that, now, it has let myopic thickies, like me, to actually see that the hardware is running ok and get to see the experimental possibilities.
Now the proof is there, getting rid of it (but leaving an archive, for others) will leave some free HUB. It might get some, like me to get back to command line again.
Heater
Would the SFU 3.5 from M$ do much the same ??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Dr_Acula said...
If you can make it run smaller/faster/neater then that sounds great!
Hopefully that board will arrive soon and you won't have to solder up sd cards etc as all the hardware will be working.
Has anyone tried to find out why only certain types of SD cards work? I mean, the others can be used on Windows, Linux, inside cameras and what not, so they can't be totally broken. Perhaps it's nothing more than some protocol violation or variation...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Dr_Acula said...
If you can make it run smaller/faster/neater then that sounds great!
Hopefully that board will arrive soon and you won't have to solder up sd cards etc as all the hardware will be working.
Has anyone tried to find out why only certain types of SD cards work? I mean, the others can be used on Windows, Linux, inside cameras and what not, so they can't be totally broken. Perhaps it's nothing more than some protocol violation or variation...
I had five SD cards 8MB, 16MB, 32MB, 256MB and 512MB. only the 256 and 512 ones would work on any Prop consstantly. The 8 and 16 were both Panasonics and never worked. The 32 doesn't have any brand name, just 0631149 written on it. A sheet I saw on it said that it was a MMC. I am sure that this one once worked in a PropCMD, but doesnt seem to want to anymore. The PC reads it ok but even my camera spits it out now.
addit All the 2GB Sandisks from the cameras work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 3/13/2010 3:46:02 PM GMT
The download is about 200MB+ and is supposed to stop people going fully over to *unix. It came from a search for the dd on windoze. But if you don't recognize it then it obviously the not one you found. Hey-Ho.
I am a bit suspicious of anything with an "F" and a "U" in it's title.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 3/13/2010 4:21:13 PM GMT
Toby Seckshund said...
The download is about 200MB+ and is supposed to stop people going fully over to *unix. It came from a search for the dd on windoze. But if you don't recognize it then it obviously the one you found. Hey-Ho.
I am a bit suspicious of anything with an "F" and a "U" in it's title.
SFU = Services for Unix. I once tried to install it and failed. It's outdated (old perl in there) and most probably way too complicated for the average Windows user to install.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I'm trying to interface the FullDuplexSerial.spin from PASM.
I added a PUB params that returns the address of the first long: @rx_head.
In my Spin code I have:
and my little routine to send a character looks like this:
'*******************************************'' Write data to the FullDuplexSerial' tx_buffer'
tx
rdlong t1, tx_head_ptr
mov t3, t1
add t1, #1rdlong t2, tx_tail_ptr
and t1, #15cmp t1, t2 WZif_zjmp #tx ' wait until there's room in the buffermov t1, t3
add t1, tx_buffer_ptr
wrbyte data, t1
add t1, #1and t1, #15wrlong t1, tx_head_ptr ' increment the tx_head
tx_ret
ret
The code seems to totally overrun the buffer. Does someone see where my fault is? I don't...
It should be doing the same as the tx Spin code in FullDuplexSerial, except for the optional rx, which I don't need.
Okay, I found it. I have to subtract tx_buffer from t1 before adding 1 etc. DUH!
So console output now goes to the serial port as well, pm80-0.2.5.zip on the first entry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I have just been catching up this am on this thread.
pullmoll: The Fat16 is there for many other reasons. I used to boot my TriBlade and RamBlade into PropCmd, but now I have SphinxOS booting and from there I can compile spin/pasm programs right on the prop and SD card. I can boot ZiCog or run whatever else I want. This means that we don't just have a Z80/CPM emulator, but prop code as well. All that remains is for the Z80 to use the HALT instruction to return to SphinxOS and we have a complete system. I expect that we will be able to run and maybe even compile Catalina and PropBasic on the prop itself before long. I am now running the later fsrw by Lonesock and Rokicki, not fsrwFemto. It is much faster, and yes once the file locations of the 8 Hard Disk files are located, we only require a small driver for direct SD sector access. We have come a long way from the old no FAT16. Just because FAT16 is used by WIndoze does not mean it isn't any good - Fat16 is supported by cameras, etc, as well as *nix I believe.
microSD cards: I have found no problems with SanDisk 2GB, but I have a SanDisk 1GB which I believe to be a legitimate one and it fails intermittently. I will not buy cheap cards and only SanDisk since these seem to be the better ones.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Just because FAT16 is used by WIndoze does not mean it isn't any good - Fat16 is supported by cameras, etc, as well as *nix I believe.
The point here was that Dr_A was trying hard to squeeze some free longs out of the code, and I then saw the rather large fsrw code which was used only to find the start blocks of the image files.
Cluso99 said...
microSD cards: I have found no problems with SanDisk 2GB, but I have a SanDisk 1GB which I believe to be a legitimate one and it fails intermittently. I will not buy cheap cards and only SanDisk since these seem to be the better ones.
I'll order one or some SanDisk then. Thanks for the info.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Comments
Ah, I see, that was what you patched. I implemented some dummy functions in io.spin for the SIMH commands and hard disk commands that the boot ROM expects. I suppose you use an I/O handler which deals with the SD cards and external memory!? I have an SD card and some USB adapter, which I don't really need. I could wire it to my board... oh, that card slot has more than 4 pins.
- 1 CS
- 2 DI
- 3 GND
- 4 VCC (3.3V)
- 5 SCK
- 6 GND1
- 7 DO
- 8 IRQ
- 9 ???
- 10+11 ?? (two pins that are very close together)
Anyone knows if I have to care about the pins 9-11? It looks like pin 9 is connected to the SD card.▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/13/2010 12:25:38 AM GMT
How log before one of you manages to compress everything into one self extracting long?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Huh? That long would probably have a value of 42.
No, actually it came to me that I was stupid to store the opcode flags inside the table. Now I store the flags in the longs that have the length of each code snippet, and that way I could change the tables to words. That got me 4*128 longs more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Ha ha Toby, now your brain really will be hurting!
Re the sd card, www.smarthome.viviti.com/propeller
Scroll down to nearly the bottom of that page to this paragraph
"Eagle files here as well as a schematic in pdf. The parts list is available here Full package of the propeller files, disk images and a terminal program here as a zip file."
and click on the schematic. Zoom into the sd card bit. Pins 9,10,11 don't matter, just leave them unconnected. SD cards are really 4 pins though there are 8 pins to connect. Gnd twice. 3V3. Pullup on pin 8. and that leaves the 4 pins DO, DI, CS and CLK
I have a vague feeling one of the other lines doesn't matter either, but I left out one pullup on one of my board designs and it stopped working so that is the schematic I am sticking with.
I/O handler for sd card etc? Yes, any I/O gets trapped in a simple spin routine
'------------------------------------------------------------------------------ ' Service I/O '------------------------------------------------------------------------------ PRI service_io | d ' d=delay 'Altair I/O simulation service loop 'I/O control block commands 'io_cmd_out = $01 'io_cmd_in = $02 'io_cmd_break = $03 repeat CheckCountdown1 ' sd card timeout CheckCountdown2 ' vga blank timeout TestPort2 ' eg #ALP or #BET, #OFF, #WHO #BYE 'vgatext.str(string("serviceio")) repeat 250 ' spend most of the time checking i/o don't make this too high otherwise the screensaver doesn't work (not sure why, must be something in the subtraction math) case io_command io_cmd_break: ' 03 on_break ' Break (for single stepping) io_cmd_in: ' 02 on_input 'An input operation io_cmd_out: ' 01 on_output 'An output operationLet's say it matches with "on_output" it will jump here:
PRI on_output 'Handle Z80 IO port writes 'simhport = $FE 'hdskport = $fd ' control port for simulated hard disk case io_port ' ledport: 'An 8 bit parallel output with LEDs attached ' out_ledport simhport: 'SIMH control port $FE ' out_simhport condata: 'Console data port out_condata constat: 'Console status port ' out_constat punstat: ' out_punstat 'Punch control port n8vem_uart_out: '&H68 out_n8vem_byte port2_io: ' for output to port 2 out_port2 port2_baud: ' set baud rate for port 2 baud_port2 Forecolor: ' set the foreground color RRGGBB00 set_forecolor Backcolor: ' set background color RRGGBB00 set_backcolor hdskport: ' $FD out_hdskport 'SIMH style hard disk port myname_port: ' port &H70 GetMyname ' returns board name in DMA 80H 'Port2_Off: ' port &H71 ' Port2_Disconnect ' disconnect port 2 control ' ram: ' write a byte to ram (port $76) ' poke_ram ' commented out as not used and takes up spin code space other: PrintStringCR(string("Er8")) ' UART.hex(0,io_port,2) 'print the port number for debugging io_command := 0 'Set flag ready for next ioSerial port I/O is pretty straightforward from here, but say you are sending to a disk, it would jump to out_hdskport
PRI out_hdskport 'Handle writes to the SIMH style hard disk port 'Handling is dispatched to an apropriate function depending 'on the command currently in progress. 'FIXME: RESET should be checked on every write no matter the command in progress. 'hdskNull = 0 ' No command 'hdskReset = 1 ' command to reset controller 'hdskRead = 2 ' read command 'hdskWrite = 3 ' write command 'hdskParam = 4 ' Get HD parameters command ' can't put diag messages in a case command, only at the beginning case hdsk_current_command hdskRead: hdsk_get_rw_params hdskWrite: hdsk_get_rw_params hdskParam: out_hdskport_param hdskReset: PrintStringCR(string("Er12")) repeat hdskNull: out_hdskport_null other: PrintStringCR(string("Er13")) repeatand now I have posted about half the code!
So maybe take a peek at the attachment especially the Main_Dr_Acula.spin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I already had your schematics. I looked at the v5 sheet.
Ok, so I have to find some 10k resistors for the lines that go to the prop. Finally found 5... done.
Ah, ok. I'll use that as a reference for my io.spin, which is in PASM.
Yep, will do after I got the SD card working.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/13/2010 1:29:59 AM GMT
Just to warn you that the make of the SD card seems to be vital. Sandisk ones have been good, the two (full sized) that work for me are "Integral" but a couple of other cards will format and load, as expected, but will not work on the Prop. Others have had this problem, on other Prop projects too.
Format them with FAT, NOT FAT32, and dump ovet the files straight away to get contiguous sectors. The drivers are very tolerant of pin location, I shifted mine over to P20-23, having restricted the VGA to four pins P16-19, with no problems. The 10K resistors do not seem to be vital but I do usually fit them, even if it is only on the /CS line.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 3/13/2010 8:34:53 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Well, I currently have just one 4GB Entryx SD card here. I'll play around with the sdspiFemto.spin to see if/how I can read from the card.
Formatting it is not a problem. I wonder why noone has written a tool to just put the required images in fixed places? You don't need a file system for how this CP/M system uses the SD cards. That could save some space on the Prop if you threw out fsrwFemto.spin. After all you don't want to modify files on the FAT(32) fs, but just write inside the images...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Those days left me floundering on how to start. As soon as the FAT way was introduced it was much more obvious.
Only the first 2G will be seen by the SPI mode, fingers crossed that it is a friendly card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Well, but it would save a lot of hub RAM if there was no fsrwFemto.spin required to access the images on the SD card.
It should be possible to write a tool that just copies the expected file images to a card on the PC.
On *nix this could even be a shell script.
Nope, it is not. The fs.mount fails. I double checked my pins and they should be ok. I attached the card slot to pins 8,9,10,11 (DO,Clk,DI,CS), because 12,13,14,15 are actually the TV output.
Meanwhile I found a couple of cut+paste bugs in the Z80 core. It now runs my own instruction tester ok - it still fails to run the EXZ80DOC.COM :-/ The only way to nail this infamous last bug(TM) will be to cycle through all instructions and look at the expected result and flags.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/13/2010 1:53:22 PM GMT
Simple and obvious.. but it leaves Windows users floundering, and perplexingly there seems to be a lot of them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Eventually I had to give in to popular demand and include FAT and image files. Windows users just don't have the luxury of dd.
Actually, Dr_A if you want to save a ton of HUB space in your DracBlades just ditch FAT and write CP/M disks directly to the SD card as God intended. After all FAT is sitting there doing nothing once CP/M is running. Just wasting precious space.
Recently I found a Windows tool that did for SD cards what dd does for Linux users. Damned if I can remember what it was called now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well, fsck the Windows users
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Nah, come on, you can just open the device with \\<device id> somehow, just as well as you can open harddisks. Then all that's left to do is some file reading and seeking + writing on the raw image handle. If all else fails, I could try to whip up a nice and user friendly (read: colorful and clickable) Windows app to do that, including a setup that asks you 7 times to click on Next
BTW while looking at Dr_Acula's code collection, specificially the main, my eyes started bleeding
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/13/2010 2:25:24 PM GMT
Hopefully that board will arrive soon and you won't have to solder up sd cards etc as all the hardware will be working.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
My plan is to create a cross platform disk sector writer using Qt.
I have never tried accessing sectors directly in Windows but it looks like it might me as simple as this.
// win NT/2K/XP code HANDLE hDevice; DWORD bytesread; char _devicename[noparse][[/noparse]] = "\\\\.\\A:"; _devicename += drive; // Creating a handle to disk drive using CreateFile () function .. hDevice = CreateFile(_devicename, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); if (hDevice == INVALID_HANDLE_VALUE) return NULL; // Setting the pointer to point to the start of the sector we want to read .. SetFilePointer (hDevice, (startinglogicalsector*512), NULL, FILE_BEGIN); if (!ReadFile (hDevice, buffer, 512*numberofsectors, &bytesread, NULL) ) return NULL; }▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It is as simple as this.. well, if you really want to call CreateFile() parameters simple. I have once tried to understand them all... Anyway, enough M$ bashing, please do it! I will buy me a SanDisk 2GB and use the same layout that you decide upon. I think the BOOTDSK_.ROM file will be the first? Then, perhaps aligned, just the 8M hard disk images?!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Now the proof is there, getting rid of it (but leaving an archive, for others) will leave some free HUB. It might get some, like me to get back to command line again.
Heater
Would the SFU 3.5 from M$ do much the same ??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Has anyone tried to find out why only certain types of SD cards work? I mean, the others can be used on Windows, Linux, inside cameras and what not, so they can't be totally broken. Perhaps it's nothing more than some protocol violation or variation...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
addit All the 2GB Sandisks from the cameras work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 3/13/2010 3:46:02 PM GMT
But that wouldn't explain why my cheapo full size SD (Entryx) doesn't seem to work, if it is required to implement SPI mode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I am a bit suspicious of anything with an "F" and a "U" in it's title.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 3/13/2010 4:21:13 PM GMT
SFU = Services for Unix. I once tried to install it and failed. It's outdated (old perl in there) and most probably way too complicated for the average Windows user to install.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I added a PUB params that returns the address of the first long: @rx_head.
In my Spin code I have:
addr := fx.params rx_head_ptr := addr rx_tail_ptr := addr + constant(1*4) tx_head_ptr := addr + constant(2*4) tx_tail_ptr := addr + constant(3*4) rx_buffer_ptr := addr + constant(9*4) tx_buffer_ptr := addr + constant(9*4) + constant(16)and my little routine to send a character looks like this:
'******************************************* ' ' Write data to the FullDuplexSerial ' tx_buffer ' tx rdlong t1, tx_head_ptr mov t3, t1 add t1, #1 rdlong t2, tx_tail_ptr and t1, #15 cmp t1, t2 WZ if_z jmp #tx ' wait until there's room in the buffer mov t1, t3 add t1, tx_buffer_ptr wrbyte data, t1 add t1, #1 and t1, #15 wrlong t1, tx_head_ptr ' increment the tx_head tx_ret retThe code seems to totally overrun the buffer. Does someone see where my fault is? I don't...
It should be doing the same as the tx Spin code in FullDuplexSerial, except for the optional rx, which I don't need.
Okay, I found it. I have to subtract tx_buffer from t1 before adding 1 etc. DUH!
So console output now goes to the serial port as well, pm80-0.2.5.zip on the first entry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/13/2010 4:40:16 PM GMT
pullmoll: The Fat16 is there for many other reasons. I used to boot my TriBlade and RamBlade into PropCmd, but now I have SphinxOS booting and from there I can compile spin/pasm programs right on the prop and SD card. I can boot ZiCog or run whatever else I want. This means that we don't just have a Z80/CPM emulator, but prop code as well. All that remains is for the Z80 to use the HALT instruction to return to SphinxOS and we have a complete system. I expect that we will be able to run and maybe even compile Catalina and PropBasic on the prop itself before long. I am now running the later fsrw by Lonesock and Rokicki, not fsrwFemto. It is much faster, and yes once the file locations of the 8 Hard Disk files are located, we only require a small driver for direct SD sector access. We have come a long way from the old no FAT16. Just because FAT16 is used by WIndoze does not mean it isn't any good - Fat16 is supported by cameras, etc, as well as *nix I believe.
microSD cards: I have found no problems with SanDisk 2GB, but I have a SanDisk 1GB which I believe to be a legitimate one and it fails intermittently. I will not buy cheap cards and only SanDisk since these seem to be the better ones.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
The point here was that Dr_A was trying hard to squeeze some free longs out of the code, and I then saw the rather large fsrw code which was used only to find the start blocks of the image files.
I'll order one or some SanDisk then. Thanks for the info.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.