• Please review our updated Terms and Rules here

A PET storage option

Emulate multiple drives?

Emulate multiple drives?

Can any of the currently-available PET drive emulators "look" like multiple attached drives?
 
shirsch said:
Can any of the currently-available PET drive emulators "look" like multiple attached drives?
Click to expand...

gubbish will give the definitive answer for his PETDisk design, but a quick trial and error indicates that no, PETDisk cannot emulate two drives (drive 0 &1) on one IEEE unit. I did properly load a file named 'test' with LOAD "0:test",9, but failed to load it with LOAD "1:test",9. Also a SAVE "0:test", 9 wrote a filename of "0:test" rather than "test".

However, two PETDisks should work properly as single drives on two IEEE units (say as device 8 and device 9).
 
At the moment, the PETdisk doesn't emulate more than one drive, but this seems possible with some software tweaks..
For support of the DLOAD command, I do parse out the '0:' before the filename, so it makes sense that "0:test" works. It's not that smart at the moment so it doesn't know what to do with "1:", but that would be simple to add.
Let me ask the PET gurus out there: what exactly is the meaning of "0:test" or "1:test"? What is the 0 or 1 referring to?
It would also be simple to have the PETdisk listen for more than one device number, so it could be device 8&9, or any other combination of IDs.
This is not in the firmware right now, but if I fully understand what's required it can be added in.
 
gubbish said:
At the moment, the PETdisk doesn't emulate more than one drive, but this seems possible with some software tweaks..
For support of the DLOAD command, I do parse out the '0:' before the filename, so it makes sense that "0:test" works. It's not that smart at the moment so it doesn't know what to do with "1:", but that would be simple to add.
Let me ask the PET gurus out there: what exactly is the meaning of "0:test" or "1:test"? What is the 0 or 1 referring to?
It would also be simple to have the PETdisk listen for more than one device number, so it could be device 8&9, or any other combination of IDs.
This is not in the firmware right now, but if I fully understand what's required it can be added in.
Click to expand...

In my case, I'd like to use a drive emulator with my SuperPET in 6809 mode to run the Waterloo tool suite. I was told by the person who sold me this beautiful beast that most (or all) of the language systems required unit 0 and 1 online (one for tools, the other for user code). The protocol for disk addressing is outlined in great detail in the Commodore Drive-subsystem docs. If you do not have access to this, I'd be willing to scan the pertinent section (although it's hard to believe that a PDF isn't available - somewhere).

I'm far from an expert in the PET architecture, but my impression is that the system ROM (BASIC?) parses file specifiers and translates 0:blah and 1:blah into "device 8, file blah" and "device 9, file blah". More knowledgeable users please forgive me if I made a hash of that explanation...

Steve
 
gubbish said:
At the moment, the PETdisk doesn't emulate more than one drive, but this seems possible with some software tweaks..
For support of the DLOAD command, I do parse out the '0:' before the filename, so it makes sense that "0:test" works. It's not that smart at the moment so it doesn't know what to do with "1:", but that would be simple to add.
Let me ask the PET gurus out there: what exactly is the meaning of "0:test" or "1:test"? What is the 0 or 1 referring to?
It would also be simple to have the PETdisk listen for more than one device number, so it could be device 8&9, or any other combination of IDs.
This is not in the firmware right now, but if I fully understand what's required it can be added in.
Click to expand...

It's quite simple. Disks drives have UNIT#s or DEVICE#s (same thing) like 8,9,10,11 etc. If a disk DEVICE has one DRIVE it is always "0". If a disk DEVICE has two drives then they are "0" and "1". If you have a DEVICE with one DRIVE you do not need to specify the "0" as it will be assumed. This is what most people are familiar with when they use a 1541 drive...

LOAD"filename",8 .... looks for "filename" on DRIVE 0 of DEVICE 8
LOAD"0:filename",8 .... does the same
DLOAD"filename" .... does the same with BASIC4 command. Note BASIC4 changes the name to "0:filename" internally before it tries to load. NOT the drive.
LOAD"filename",9 ..... looks for "filename" on DRIVE 0 of DEVICE 9

Now, on a DUAL drive like the 4040 or 8050 etc:

LOAD"1:filename",8 ... looks for "filename" on DRIVE 1 of DEVICE 8
DLOAD"filename",D1... does the same
DLOAD"filename",D0 ... looks for "filename" on DRIVE 0 of DEVICE 8
LOAD"1:filename",9 ... looks on DEVICE 9
DLOAD"filename",D1 on U9 ..... does the same... DRIVE 1 of DEVICE 9 (UNIT 9)

Steve
 
sjgray said:
It's quite simple. Disks drives have UNIT#s or DEVICE#s (same thing) like 8,9,10,11 etc. If a disk DEVICE has one DRIVE it is always "0". If a disk DEVICE has two drives then they are "0" and "1". If you have a DEVICE with one DRIVE you do not need to specify the "0" as it will be assumed. This is what most people are familiar with when they use a 1541 drive...

LOAD"filename",8 .... looks for "filename" on DRIVE 0 of DEVICE 8
LOAD"0:filename",8 .... does the same
DLOAD"filename" .... does the same with BASIC4 command. Note BASIC4 changes the name to "0:filename" internally before it tries to load. NOT the drive.
LOAD"filename",9 ..... looks for "filename" on DRIVE 0 of DEVICE 9

Now, on a DUAL drive like the 4040 or 8050 etc:

LOAD"1:filename",8 ... looks for "filename" on DRIVE 1 of DEVICE 8
DLOAD"filename",D1... does the same
DLOAD"filename",D0 ... looks for "filename" on DRIVE 0 of DEVICE 8
LOAD"1:filename",9 ... looks on DEVICE 9
DLOAD"filename",D1 on U9 ..... does the same... DRIVE 1 of DEVICE 9 (UNIT 9)

Steve
Click to expand...

Yes, and from what I'm told the Waterloo tools assume that D0 and D1 are online and available (the system was expected to have a dual drive attached with diskettes in both).
 
I want to propose an idea for discussion:

We use folders on the microSD card to simulate devices and drives.
We can discuss the specifics, but I'm thinking:

\DEVICE8 - folder for device 8
\DEVICE9 - folder for device 9
\DEVICE8\DISK0 - folder for Device 8, disk 0
\DEVICE8\DISK1 - folder for Device 8, disk 1
\DEVICE9\DISK0 ... etc

I guess you can decide how flexible you are. For example if there are no DEVICE folders you can default to the device selected by the hardware jumpers. If there are no DISK folders then you assume all files in the root are for DISK0.

This will allow maximum flexibility. We can have single or dual drives, or multiple drives as needed. Once that it working we could think about adding additional folders to simulate additional disks, such as:

\DEVICE8\GAMES\ - a games folder

Then you could do something like: LOAD"GAMES",8 and it would select the GAMES folder

Steve
 
Thanks for the explanation of drive addressing, this makes sense to me.
The protocol for disk addressing is outlined in great detail in the Commodore Drive-subsystem docs. If you do not have access to this, I'd be willing to scan the pertinent section (although it's hard to believe that a PDF isn't available - somewhere).
Click to expand...
Most likely this is available somewhere - just did a quick google search but didn't see it. If you do have a chance to scan the section, shirsch, that would be much appreciated, but I'll do a more detailed search for the document when I get some time.

\DEVICE8 - folder for device 8
\DEVICE9 - folder for device 9
\DEVICE8\DISK0 - folder for Device 8, disk 0
\DEVICE8\DISK1 - folder for Device 8, disk 1
\DEVICE9\DISK0 ... etc
Click to expand...

I think this is a great idea! And not terribly difficult to implement. I like the idea of how to select the subfolders as well.
Anyone want to help hack on this? :)

Also, if anyone has a pointer to documentation on how sequential/relative data files work, it would be much appreciated.
Thanks,
- Mike
 
Thanks very much for the documentation.. Will read through these.
In the meantime, finishing up with support for saving long file names. It is mostly working, except I need to fix something with the long directory entry. Will post this as soon as it's ready, hopefully tonight or tomorrow morning.
- Mike
 
PETdisk firmware v1.21 ready

PETdisk firmware v1.21 ready

Hi there,

Just finished up the code to support saving long file names. Just had to understand FAT32 long directory entries first..
I've put up the firmware file at:
http://bitfixer.com/bf/data/firm0121.bin

To update your PETdisk:
- format your SD card with FAT32
- copy the firm0121.bin file onto the card. It needs to be the first file copied onto the card for the PETdisk to find it.
- insert the card into the PETdisk and power up. By the time the PET is ready, the bootloader will have rewritten the program on the PETdisk.
when you do a directory, you should see "PETDISK V1.21"

More updates following soon.. things are getting hectic with work so I will have limited time for the next couple of weeks, but will try to keep things moving. Some folks have mentioned the possibility of porting the SD2IEC firmware to the PETdisk, which I think is quite possible. Next time I have some time I'll investigate further.

Anyway enjoy your weekend and your vintage computers,
- Mike
 
gubbish said:
Some folks have mentioned the possibility of porting the SD2IEC firmware to the PETdisk, which I think is quite possible.
Click to expand...
The mega8 used in first versions of PETdisk has 8 KB flash memory, the later replacement mega168 has 16 KB flash. The pincompatible replacement offering the most flash space would be the mega328 with 32 KB flash.

The sd2iec firmware development startet with a mega32 (32 KB flash). The last version that fitted into the mega32 was 0.6.7a from March 2009. The current version needs a mega644 at least (64 KB flash) and is on the way to need a 1284p (128 KB flash).

So shrinking the sd2iec firmware to fit into a controller that offers the half or even quarter size where it started sounds like a challenging task to me.
 
Thanks for the info.. that does sound like quite a squeeze. I think there are large sections that could be removed, such as processing serial iec commands from the C64, or support for funky bootloaders, but likely it will still be a challenge to get everything to fit on the atmega168. Moving to the 32k part sounds reasonable if using a 2009 version of sd2iec is acceptable.
In any case, realistically I won't get to this right away so for now I'll make incremental improvements to the homebrew PETdisk firmware. Any AVR developers want to try their hand? :)
 
Hi all,

Starting to look at implementing support for read and write of SEQ files.
I've read through the description of sequential files in the drive documentation, as well as some documentation of Commodore DOS.. forgive me for my limited understanding!

My understanding of sequential files is as follows - please let me know if I'm missing something here.
To create a sequential file, you would do an OPEN command, of this type:
OPEN 5,9,3,"0:SEQFILE,S,W"

After which you would write data to the file by doing
PRINT#5,"something" or PRINT#5,A$

and the file would be closed by doing
CLOSE 5

To read from the file, you would do an open file like
OPEN 5,9,3,"0:SEQFILE,S,R"

and read data with either
INPUT#5, A$

or
GET#5, A

And you would close the file as before with
CLOSE 5

This is my current, probably limited, understanding - If you see any obvious things that I am missing here, please let me know.
I'm also looking for a piece of PET software which utilizes sequential files that I can use for functional testing of my code.
I just tried running Pascal on a PET 2001, which loads but then asks me to "press play on tape #8".. so I'm not sure what's going on there. It does say "(8032)" after the program loads so perhaps it requires an 8032 to run properly? Not sure.
In any case if you can point me to some software which would be good for testing SEQ functionality, please let me know.. Thanks!
Hopefully will have this feature ready soon..
- Mike

Thanks!
- Mike
 
One of my test programs was this:

Code: 
  100 open 1,8,3,"0:fruits,s,w"
  110 open 2,8,4,"0:veggies,s,w"
  120 print#1,"apple"
  130 print#2,"potato"
  140 print#1,"banana"
  150 print#2,"carrot"
  160 print#1,"cherry"
  170 print#2,"broccoli"
  180 close 1
  190 close 2
  200 open 1,8,3,"0:fruits,s,r"
  210 open 2,8,4,"0:veggies,s,r"
  220 input#1,f$ : print f$;st;tab(20);
  230 input#2,v$ : print v$;st
  240 if st<>64 then 220
  250 close 1: close 2

It opens two files at the same time, writes something in, closes the files and reads it back - again both files opened at the same time.
If you look at the BASIC command OPEN 1,8,3: the IEEE bus sees only 8 (unit address) and 3: secondary address. The secondary address is used to distinguish between different files if multiple files are open. Consequently, you can not have opened more than 15 (16 minus 1 for status/command channel) files at the same time at a single device - no problem back in 1981.

It is important to understand, that PRGs and SEQs are the same. Since the PETdisk can LOAD and SAVE, you have seq-files as well. The only difference is the file type, or extension if we're on a FAT file system-- but that is invisible to the IEEE bus.

Have a look at the options for the open command in the disk manual:
- s = seq file
- p = prg file
- r = read
- w = write
- a = append

If you do not give these options, the drive uses default values. s for seq is default, so you could use open 1,8,3,"fruits,w" as well.

Secondary address 0 and 1 are used for load and save. That means, if the drive sees this secondary addresses, it knows if you want to read or write and it knows the filetype prg. But besides that, these are ordinary seq files just like any others.

Try the following program. It will SAVE some fruits and LOAD them back. I hope this helps to understand, that seq files and prg files are the same.

Code: 
  100 open 1,8,1,"prgfruits"
  120 print#1,"apple"
  140 print#1,"banana"
  160 print#1,"cherry"
  180 close 1
  200 open 1,8,0,"prgfruits"
  220 input#1,f$ : print f$;st
  240 if st<>64 then 220
  250 close 1
 
that's a great explanation from for,, !

Looking at my documentation, maybe this option can be coded since the beginning :

open 1,8,3,"0:fruits,s,w"
Click to expand...

if you code "@0:fruits" ; the SEQ file "fruits" will be replaced if it exists and the mode =W

Cheers,
 
Eudimorphodon said:
...In another random question, anyone know of a good (downloadable from somewhere) PET-compatible disk utility to facilitate things like copying files from one disk unit to another? LOAD followed by SAVE works, but...
Click to expand...
Here's Commodore's Unit to Unit program. Don't know if it works with the new PETdisk because I haven't picked mine up yet, but it would be good if it (or an equivalent program) did work.

View attachment U2U.zip
 
You must log in or register to reply here.
Back
Top