Hard Disk Boot says "Loading from 0"?

[Mark Lawler]

I recently sold my house, lived in an RV for 3 months, bought a house, moved in, unpacked, etc.  As such my Altair-Duino 8800 replica and PiDPs sat backed in boxes for a while.  I've been able to get everything running as before except for my Altair-Duino and I suspect it may because I mistakenly left something off of the cheat sheet I created years ago and haven't followed for about 5 months now.

With A12 selected I pick a floppy that has my programs saved on it and depress Aux 2 which mounts it.  I then select A13 & A12 and pick my hard drive image and depress Aux 2 which mounts it.  Lastly I use the switches to set 00001110 (Hard disk boot ROM), but I see the following when I depress AUX 1:

     [Running hard disk boot ROM]

     HDBL 2.0

     LOADING FROM 0

then the display freezes although it appears the emulator is running some program in a loop as I can stop, single step, run, etc. with the front panel behaving as it should.

Any ideas why I'm seeing LOADING from 0 then nothing?  I'm used to the disk image booting CP/M..

I've even tried booting off a mounted floppy with 00001000 (Disk boot ROM) selected and what I see after pressing AUX 1 is: 

     [Running disk boot ROM]
     CCCCCCCCCCCCCCCCCCC <C's forever scrolling vs. booting off that floppy>

Thanks!

-Mark

[Mark Lawler]

Hmmm...  Upon closer inspection, after I removed the Altair-Duino add-on board for VT100/Serial/Audio/SD Card/Power card, it appears that the SD Card Module decided to eject the thin metal cage that it uses to hold the SD card firmly against the contacts.  I suspect that after no longer having a firm slot for the SD card to fit into, the inserted SD card wasn't making good contact with the SD Card Module.  Time to get out the soldering iron to attempt a bush repair to reattach the cage given I don't have any replacement SD Card Modules handy.  Best...

[John Galt]

I just put this out there as additional. not related to hardware breaking etc..

I've had altair-duino that sat for a long time then when i went to go use them they acted all strange for while until it was powered for a while.

i had to keep power cycling them and flipping the switches seeing if it was oxidation or something.

Then i had one of the SD cards start to corrupt data when it sat.

I would boot a disk image and it would lock up the system or i would be able to list the directory and when i run the binaries it would lock up or show Read/Write errors.

the only way to fix it was copy over the disk image again with a fresh copy.

I've had similar happen to the IO BUS where somehow its acting all messed up and i leave the power on for a while and it magically fixes itself.

just as a precaution i recommend backing up your micro SD cards especially if its going to sit unused for a few months.

when i looked into micro SDs it appears other people have experienced them corrupting over time, also if you use them a lot to read/write they can go bad.

as a general backup these are not good long term.

i have one altair-duino that i use at least a few times a week and have not had issues.

i have another altair-duino that does not get much use maybe once every 2 weeks and that one has gone funny a few times just from sitting.

then i have a third altair-duino i was using to prototype things and it sat for over a year and when i powered it up it was like it had alzheimer's

slowly over an hour of power cycling and leaving it powered while i tried to figure out what was wrong with it it started working correctly.

but i did have the SD card start to corrupt on the second altair-duino where i had to replace 2 disk images that went strange.

then on the third one that sat i left the SD card on the shelf in a case and that card just went wacko for no reason and i refreshed it and it worked fine.

just remember to backup your work from time to time and do not 100% trust it unless you use it constantly.

[Mark Lawler]

Yes, backups of these SD cards is very important...  Especially as we develop new software to run on them using native editors, compilers, assemblers, linkers, etc.  I don't know about you, but using XMODEM to send important files to other systems for safe keeping, although appropriate for the time period, is so tedious... :) 

My soldering iron hack to repair the SD Card module worked, reattaching the metal "cage" that holds the SD card in place when inserted.  The system is working again which makes me happy.  But then yet, wasn't it actually "working" all along?  Had the hard drive cable been disconnected or some other fault on the drive would I have seen the same behavior on the original?  :) 

Best,

-Mark

[John Galt]

Much of the software for file transfer was locked into 9600 Baud.

pcput, pcget,  Kermit and IMP versions available run at 9600.

there is a high speed version of IMP requiring patching but it seems to need a 4MHZ cpu to run above 9600.

i've tried connecting at 19200 externally to devices and the Arduino due seems to start having issues. internally i have run the system at 19200 and seen how much faster it runs.

disk access and screen refreshing and keyboard input is more responsive. there is some bottle neck that occurs when you talk to the external 232 and it starts dropping characters or goes out of sync as the Due is just not fast enough. 

9600 is the most stable.

There is CP/NET that emulates a cp/m disk over serial, but it also seems to want 4mhz cpus to run at fastest serial speeds. some debate on how convenient this is.

you have the extra step of having to use cpmtools to rip a file out of the disk image and also put it back in if needed. 

I use a dedicated usb to serial connection for file transfers but you will never see the full 9600 speeds so it takes longer then 18 minutes to transfer 1mb files.

other then the quick method of coping the contents of the SD drive and using CPM tools to pull files out from the disk images there isn't much.

i have a raspberry pi on my serial port switch where i can transfer files and store them on the pi or use that pi to transfer to other machines.

wifi modems cause additional speed bottlenecks so i stopped using them unless i want to create a wifi serial bridge directly between 2 machines but again it is slow.

compression is your friend as it will help speed up transfers and also adds a level of corruption protection to your file storage.

LBR, Archive.

my source code i develop on modern machines then bring them onto the Altair-duino its just easier. no point in self torture using some vintage editor.

the big issue is long term corruption of data which i have experienced over the last 5 years (bought my first emulator back in 2020)

interesting to note that when i first received my pro KIT i found my new SD card that came with the kit was corrupted. many people have experienced SD weirdness and the truth is sd cards are more unstable then people think they are.

on the 3d printer end of things i have burned through 3d cards and USB sticks as well. either they internally fail over again over time they start to act strange and corrupt data.

going back to 9600 baud.. i have had various dot matrix printers experience dropping data with the aurdino DUE above 9600 baud once machine was having issues even at 1200 with the DUE.

after 5 years of me playing around i just kept going back to 9600 baud and basically leaving it there unless i was doing something that didn't need external serial connections.

i will say that if you have not used a direct cable connection and have been using the WIFI in my experience you will see a massive speed increase ditching the wifi.

[mark.lawler]

Was there a 9600 baud modem available to mere mortals back in 1972?  I was stuck with 300 back in the day; I upgraded to 1200 around 1983.  For me 9600 was in the 90's... <grin>

Autocorrect is not my friend... 

--
You received this message because you are subscribed to a topic in the Google Groups "Altair-Duino" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/altair-duino/yy9VnewDYWU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to altair-duino...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/altair-duino/622c15c3-98e4-45d0-9980-3153264dc827n%40googlegroups.com.

[John Galt]

9600 baud modems not that early. modem speeds at that rate were available in the late 1980s into the early 1990s

A lot of the cp/m software was in use into the 1990s. much of the software was patched to use 9600 baud.

[David Williams]

Serial connections were also sometimes used between directly connected CP/M machines since they often couldn't read each other's disks. If you bought a new Kaypro II, and wanted programs or data off your old 8" disk system, serial was it.

[John Galt]

you could use PIP for that

http://www.toniwestbrook.com/archives/80

it is a very primitive method using PIP usually you try to copy over imp, kermit or pcget as a first program. it acts like a bootstrap if the new machine does not have any better transfer programs preloaded on the disk.

getting around disk format issues so you could just copy the binaries from one machine to another when the two machines could not exchange disks directly.

[mark.lawler]

PIP was (still is) my favorite command ever!  Anything it cannot do?  ;)

To view this discussion visit https://groups.google.com/d/msgid/altair-duino/347df664-4ed0-4bc5-8312-cb77ca9e0606n%40googlegroups.com.

[David Williams]

PIP doesn't do any error detection. I'd only use it to transfer proper transfer software.

[John Galt]

PIP does have a verify option. [V] 

Not a great replacement for better error detection.

[David Williams]

I think the PIP verify just reads back to verify that the data was written correctly. I'm not sure it does anything useful for a serial transfer.