archive.worldofdragon.org

jedie wrote:On the Client i using RESAVE. On the server side: I can't "see" when a incoming file is complete, isn't it? The is no information how many 256 Bytes chunks will be send or if the chunk is the last chunk, isn't it?

If I understand it correctly, the server does not know about files because it works at the sector level. The virtual serial ports may have something but I haven't looked at it very closely.

It is like a disk controller. It does not know when you have finished writing to it.

If you want your server to take some action on 'completion' of a file you will need to decode the payload as you suggested.

Seems to work: https://github.com/6809/DwLoadServer/co ... 50bed69a0d

A DLOAD"RESAVE""FOO.DWL" will saves the normal "FOO.DWL" in Dragon DOS Binary Format.

I check if content.endswith(b"\x00\x00\x00") after every block. If it's true: a server hook saves "FOO.DWL.BAS" in ASCII

WIP: the ASCII load...

(jedie, maybe we can move the discussion of your python server to another thread, because the problems you are having are not relevant to "normal" users using DriveWire4 and might add confusion here. I am sure it will be a useful alternative once it works though.)

I found this very interesting information a bit hidden on the DriveWire4 homepage: https://sourceforge.net/p/drivewireserv ... h-cocoboot
Apparently there is already an option DiskPadPartialSectors that will make DriveWire4 pad all files to multiple of 256 bytes for us!

Also the NamedObjectDir sounds like something many people have requested, to keep files and dweebs in a folder outside the DriveWire4 folder.

tormod wrote:I found this very interesting information a bit hidden on the DriveWire4 homepage...

A good find!

The 'NamedObjectDir' setting does indeed allow you to change the location of the files accessed by DLOAD.

If the following line is added to config.xml inside the <instance> section, the setting can be edited in the config editor:

<NamedObjectDir type="directory">c:\DriveWire4_4.3.3\dload</NamedObjectDir>

I couldn't get the 'DiskPadPartialSectors' setting to work though, and the server still threw an error when accessing an unpadded file. Has anyone else had better luck?

tormod wrote:(jedie, maybe we can move the discussion of your python server to another thread, because the problems you are having are not relevant to "normal" users using DriveWire4 and might add confusion here. I am sure it will be a useful alternative once it works though.)

No problem. I would like to discuss DWLOAD related things here and my DW-Load-Server related things there: viewtopic.php?f=8&t=4946

But there a Question about the existing "AUTOLOAD.DWL" example file / Dragon Dos binary file specs:

I analyse the existing "AUTOLOAD.DWL" example. Extracted values are: If i strip the file with this given length to remove the padding i get this: IMHO there are to many $00 at the end, isn't it?

The last code line is: 540 GOTO 7 -> the last code char is "7"==$37
After $37 are 5x $00 but IMHO 3x $00 are enough:
1x $00 -> BASIC line end terminator
2x $00 -> Listing end (Next address)

In http://dragon32.info/info/binformt.html is this information:

LENGTH is length if DATA block that follows i.e. complete file should be
LENGTH+9 bytes long

So, is the length information in the generated "AUTOLOAD.DWL" is wrong? Or is http://dragon32.info/info/binformt.html wrong and Dragon Dos binary files has a terminator with 2x $00 extra bytes?!? Or, the likely case: I'm wrong



EDIT: I try to figure out:

Listing: "10 CLS" and requested DLOAD"SAVE""CLS.BAS"
I get this:

Data: 1e 07 00 0a a0 00 00 00

blue: next address
green: line number (=10)
a0: CLS
red: line end + next address

All together are 8 Bytes.

So: The length value in "AUTOLOAD.DWL" is wrong?
@tormod: How do you generate this file?


EDIT2: Seems that i'm right: The origin "AUTOLOAD.DWL" length is $025c (dez.: 604 Bytes) but if i SAVE the AUTOLOAD file, i get $025a (dez.: 602 Bytes) back.

sorchard wrote: If the following line is added to config.xml inside the <instance> section, the setting can be edited in the config editor:

<NamedObjectDir type="directory">c:\DriveWire4_4.3.3\dload</NamedObjectDir>

I couldn't get the 'DiskPadPartialSectors' setting to work though, and the server still threw an error when accessing an unpadded file. Has anyone else had better luck?

The same happened to me.
No problem to tell DW4 where the named_objects are, but it doesn't do anything with the DiskPadPartialSectors ... despite it appears in the config window (?)

cheers
pere

Does anyone know whether FLEX can be booted via DWLOAD-Drivewire? It works in XRoar when a DragonDos 1.0 rom sits in XRoar's rom path.

On both XRoar configured for DWLOAD-Drivewire and on a real Dragon 64 fitted with the DWLOAD rom, I have tried to use the LROM DWEEB to load the DragonDos rom with a padded FLEX vdk (from the archive) sitting on the DriveWire Server, but the Dragon complains that it runs out of space when DLOAD'ing LROM. The DOS DWEEB does not boot the disk either.

Is a new DWEEB and/or Drivewire support for DragonDos disks needed for FLEX to run?

DriveWire is not compatible with the disk controller that FLEX assumes. You can probably load the boot record from the Flex image, but once the boot program tries to read the rest of the OS image it will try to access a disk controller and not DriveWire. A patched FLEX distibution is needed, or a DragonDos-compatible DriveWire driver.

-- Rolf

Hi all,

Having been somewhat absent from the Dragon scene for many years I've been somewhat taken by the whole drivewire concept, possibly because it has echoes of my PCShare project I did in the 90's - see http://www.onastick.clara.co.uk/pcshare1.htm - the major drawback of this what the amount of hardware modifications needed to get it to work. I'd fairly well ignored using serial as the underlying protocol knowing that the D64 serial port tops out at 19200 and I'd always read that the CoCo's bitbanger was limited to around 1200baud for reliability, hence my approach of using 8-bit parallel transfers. So it's impressive that people have managed to crank up rates of 56K using the bitbanger approach. It's a shame that the native D64 serial port can't go at those sort of rates (& higher) as that would negate the need for any additional mods at all (& may well prove even quicker due to less CPU overhead).

I had in the back of my head that any future stuff I develop for the Dragon would be developed under Linux (or similar) in either assembler or C (using the 6809 cross compiler) the question was always having a convenient means of loading it onto the machine and DWLOAD looks like the ideal solution. Planing to get a couple of EPROMS blown next week so I may well get a modified DWLOAD D64 one done at the same time.

One question then, it was mentioned that there were extensions available to read DragonDOS VDK images but haven't seen any references as to where to get them. That would be really useful in terms of interchangeability between files stored on DOS images and "real" files held on the Driveware server (if you get my drift).

Rgs,

Jon.

hello Jon,

you will find some dweebs to work with VDKs here:
viewtopic.php?f=5&t=4968

These help in copying a whole VDK to a real floppy or viceversa (V2FLO and FLO2V)
Then you have VDIR to see the files in a VDK
And finally VLOAD that lets you load/run any program inside any VDK (requieres TABLDR)

Lately I haven't got time to begin with other projected dweebs, hopefully I would be able to create them soon
The idea is to add a copy facility to send a file from inside an VDK to a floppy or the other way round (so, 2 dweebs)
Then I would like to be able to save anything from memory to VDK, lets say BAS or BIN/DAT (2 more dweebs)

In fact the beauty of DWLOAD is that you put the limit, that's to say, once you learn how to implement a dweeb,
you can really do what you could imagine.

cheers
pere