• Please review our updated Terms and Rules here

Petsd

Right now only SAVE and LOAD commands, but he is looking into adding DOS Wedge shortcut commands.

Okay. I was mostly just curious about the DOS wedge stuff because I'm trying to justify my decision to go with BASIC 2.0 instead of 4.0 for the project I'm working on. I know BASIC 4.0 has improved garbage collection, but my impression at least was almost all the rest of that additional 4k it takes up was the DOS extensions.

Why would anyone want relative file support? Are there any legacy programs that use them? The biggest name database program is 'Data file Handler' and its only uses .seq files albeit with assembly routines.

Personally I don't really care; if it can do .seq that probably covers any use case I might care about.
 
I've got my webserver running on a synology with php installed.
Any webserver that supports php should work.

Is the php script available? Does it go into the same directory as the PET program files? This feature sounds very useful. LOAD "program_name", 10 and whoosh, a PET program downloaded from the ether directly into the PET.
-Dave
 
Is the php script available? Does it go into the same directory as the PET program files? This feature sounds very useful. LOAD "program_name", 10 and whoosh, a PET program downloaded from the ether directly into the PET.
-Dave

You'll have to wait for bitfixer to release it, like I said, I'm just helping beta test.
 
Right now only SAVE and LOAD commands, but he is looking into adding DOS Wedge shortcut commands. He is also looking into a wifi interface where one can download (LOAD) program files from an internet site. It works in beta testing.

Why would anyone want relative file support? Are there any legacy programs that use them? The biggest name database program is 'Data file Handler' and its only uses .seq files albeit with assembly routines.

REL support is important if you have a SuperPET and want to run SuperOS9.
 
REL support is important if you have a SuperPET and want to run SuperOS9.

OK, that would be useful. But are you able to run the Waterloo 6809 code without SuperOS9 on the SuperPet? That is, run Fortran, etc without SuperOS9?

Also I think to run the SuperPet, the disk emulator would have to differentiate between drive 0: and drive 1: on the same device number drive. Not many do that.

I'd like to get a SuperPet one day. I think running FORTRAN IV on a Commodore PET would be amazing.
 
OK, that would be useful. But are you able to run the Waterloo 6809 code without SuperOS9 on the SuperPet? That is, run Fortran, etc without SuperOS9?

Also I think to run the SuperPet, the disk emulator would have to differentiate between drive 0: and drive 1: on the same device number drive. Not many do that.

I'd like to get a SuperPet one day. I think running FORTRAN IV on a Commodore PET would be amazing.

Yes, that's correct. You need two drives on the device. XD2031 will do this properly and Andre' recently fixed some problems with REL handling that had prevented OS-9 from working. I'm currently using an original PetSD with XD2031 firmware tethered to a Beaglebone running the server. It's a bit messy to have it all connected up and an all-in-one solution would be good as an alternative. Even more recently I fixed some longstanding problems in the SSE 'Hardbox' (Corvus interface for IEEE bus) and have hard drive support as well :-).
 
Been a while since i've done much with my pet but wanted to update this thread for folks. One of the items with this petsd+ that always kinda bothered me was that my screen wasn't backlit up so it was hard to read. finally looked at the schematics to see what I could do about that and noted that the backlight was linked to 'JP1' next to J1 which wasn't mentioned in the documentation (that i saw). Soldering a connector there and putting a jumper on it (or I guess just wiring it up directly) gets the backlight to work. Anyway, just an FYI for folks building this, if your lcd of choice needs it.
 
Another thread update.. needed a case and none seemed to exist that you could print yourself. There's a pretty nice one that people can (maybe?) buy, but didn't seem worth it with the petsd+ development being abandoned - better to spend the money on one of the newer solutions. This one isn't anywhere near as nice as that case, but it'll do the job.

 
Another thread update.. needed a case and none seemed to exist that you could print yourself. There's a pretty nice one that people can (maybe?) buy, but didn't seem worth it with the petsd+ development being abandoned - better to spend the money on one of the newer solutions. This one isn't anywhere near as nice as that case, but it'll do the job.


I like this one https://www.tinkercad.com/things/iu8w26e5DdN-petsd-case-top-button-rev-13

I little fiddly to get together, but prints easy and looks somewhat "fancy".PXL_20210326_180309332 (1).jpg
 
I like this one https://www.tinkercad.com/things/iu8w26e5DdN-petsd-case-top-button-rev-13

I little fiddly to get together, but prints easy and looks somewhat "fancy".

Oh man, that would have been nice to know about a few weeks ago.. Haha.. I checked thingiverse and printables and there was nothing on either site. I didn't even know tinkercad had a place to share models (which is actually where I made mine). Anyway, thanks for sharing... so people at least have another option.
 
Last weekend I finally built up a cbmSD-mini using one of Steve Gray's v1.1 PCBs. Unfortunately I cannot get any signs of life out of it when connected to the SuperPET. The CPU is definitely running. I was able to flash the bootloader and it programs itself properly when a new PetSD+.bin file is in the root of the SD card. One symptom: The unit seems to have a lot of trouble resetting itself. It lights both the Error and Busy LEDs, then the Error LED goes out followed by the Busy LED flickering and coming back on. I read about issues with newer firmware - and - about a method for reliably resetting by pushing the button while both LEDs are on. However after going back (5) versions in firmware and a LOT of button pushing it will end up with both Error and Busy extinguished about one in ten times.

With the cbmSD-mini in a proper reset state and connected to the PET, I get absolutely no signs of life when it's addressed. I would have expected a flicker from the Busy LED on access, but nada. I've replaced both IEEE bus transceivers with new chips, but that did not change anything. I know the PET is working correctly since it addresses my legacy PetSD with no problems.

The v1.1 PCB had some known layout issues (which I've corrected), but I'm concerned there may be others. However, after laboriously checking continuity point to point I cannot find any opens or shorts. Has anyone here built a cbmSD-mini using the v1.1 board? Any suggestions for further debugging? I do have a couple more atmega1284p chips on the way in case I ended up with a dud, but it really does act like it's alive.
 
I have solved the problem! All the documentation I found implied that the default unit # was 8. That is NOT correct. It is 11. And with that everything has come to life.
 
Back
Top