how to made os65 floppy image ?

[wawa.voun]

Hello there,

On a pc I have a text file containing a basic program.

Is it possible to put this into a os65 disk image ?

I suppose the text basic should before be tokenized and only after be add to an disk image.
After that I have already use OSIHFE so no problem with the gotek.

If no solution I will try with the serial port...

Regards.
Philippe

[wawa.voun]

Tokenize = OK !

Thanks to Mark's DeToken program.

[Mark]

I'm currently looking into writing another utility or adding this functionality to manipulate dump/hfe images.

Most OS65D data and executable files on disk start with a 5 byte header and are located at the start of the work area in memory.
The header starts 5 bytes before the work area address.
So if you are using 5.25" OS65D3.3, the work area starts at $3A7E. The header (starting at $3A79) contains starting address lo,hi end address lo,hi and number of tracks occupied. Then the data (Tokenized BASIC, Assembler listing, or machine code program starting at $3A7E) follows.
OS65D3.3 8" Seems to start at $317E, OS65D3.2 5.25" Starts at $327E

It turns out you don't need to know what OS version you are running a BASIC program on (as long as tokens are correct) as the loader relinks the BASIC program for the current workspace start. The BASIC programs on disk that specify a starting address as $327F correctly load on a BASIC with a workspace start at $3A7E or higher.


A way of transferring BASIC programs inside of OS65D via serial port is to create an empty file on disk using CREATE utility to prepare for your program. Then boot BASIC. Use the command DISK!"IO 01,03" to redirect input from serial port, output to screen and serial port. Send the BASIC text from your terminal program. (A syntax error will reset input to OSI keyboard, so you'll have to redirect input again.) If your default I/O device is already serial port, there is no need to redirect I/O. There is a POKE to set OS65D default devices to survive syntax errors, but I don't have it handy.

Anyway after transferring the program, enter DISK!"PU FILNAM" to save your program.
To get BASIC files off of OSI, you can send output to screen and serial using DISK!"IO ,03" then LIST the program to send it out.

I'm happy you figured it out!

-Mark

[bxdanny]

Hi Mark. I just want to give you a big thank you for your continued work on WinOSI. I didn't think you would be able to get the hard disk emulation working, but you did it.

Wawa.voun, if I understand your question correctly, you could use Mark's emulator to move files between the PC and OSI disk images on the gotek device. Boot up 65D on the emulator, use "attach serial input file" to select your BASIC program text file, then DISK!"IO 01" (or the equivalent POKE 8993,1) to take input from the file. Save the resulting program to the disk image you are using, and take that image to the OSI.

Or am I missing something about this HFE/Gotek device or what it is you have "no problem" with?

[wawa.voun]

Hi,

This is right. Thanks Mark for your support and your work !

Finally my questions is : is there a way to build from scratch a OS65 image on a pc (dos, windoze or linux) computer ?

After this step I can move this image to hfe file and read it into OS65 via the gotek.

Regards.
Philippe

[wawa.voun]

Hello,

I am not far to do what I want using Mark's the emulator...

After using DISK!"IO 01" and reading from serial file what should I do to come back to the keyboard input so I can save the basic file to disk image ?

Should I add something like DISK!"IO 00" at the end of the file ?

Regards.
Philippe

[wawa.voun]

DISK!"IO 02" do the job !

[wawa.voun]

Problems with the emulator...
Lot of errors after some jobs on the disk images (I start from tut 5 disk image but after some deletions with bexec the image become unusable, delete do the job but finish by an error and dir and create stop to work...).

But I finally got a success with serial transfer from linux console...

I write a batch file which read into text file char by char and send it to /dev/ttyUSB0.
I have just to add a pause of 0.2s in the batch file after sending each character, I suppose it is required due to tokenization time.

It is slow but works well.

Thanks for the suggestions and the help.

Philippe

[bxdanny]

Hmm. Actually, I have had some trouble too with the latest versions (1.6.x, really 1.6.5 for me) of the emulator, when updating disk images. The writes to the first directory sector go too far and overwrite the second sector, making it (as well as sectors 3 and 4) disappear. Possibly this is because the original images had too little space between sectors; I know the (emulated) disk timing was changed with version 1.6.5. Possible fixes are:

1) Use the older (1.5) version of the emulator instead, as it didn't have this problem. Or
2) Re-write all of track 8 (for 8", track 12 for 5.25") before starting updates to the emulated disk. For example:

EXIT
CA 6000=08,1
CA 6100=08,2
CA 6200=08,3
CA 6300=08,4
SA 08,1=6000/1
SA 08,2=6100/1
SA 08,3=6200/1
SA 08,4=6300/1
RE B

This should only have to be done once to a given disk image, after which the directory can be updated repeatedly.
Copying the disk image to a new one with the disk copy function should also do it, I think.

Mark, are you reading this? Maybe I should email you directly.

BTW, when I tried to install 1.6.6, directly over 1.6.5 using the installer, the resulting version would not boot 8" (or hard drive) images at all. So I used System Restore to go back to 1.6.5. I don't know just what happened, maybe something corrupted during the update process?

[Mark]

Hi, thanks for the bug report.

I have an update to WinOSI V1.6.8 that resolves the problems you mentioned at https://osi.marks-lab.com
The disk problem was due to the introduction of high water marks on the disk tracks. These are generated by the OSI Disk Tool to indicate how much data was actually read from a disk. It differentiates between a disk of OSI encoded zeros and a disk with no data at all except sync, and is used in the reconstruction of disk images (HFE). (Iniz? OS65D disks only have 4 bytes of real data on a track.) Unfortunately old disk images don't have these - no problem, the emulator reads to the end of track. Format or DiskCopy a new emulated disk? The high-water mark is set. However the error occurred on OS65D when you rewrite a lower sector. The high water mark is moved from <uninitialized> to End-At-Sector-Written, which means the follow sectors became "invisible" since they were after the high water mark. OS65U writes whole tracks at a time as do other OS's and were not affected. Anyway that's been resolved. No data was actually lost, just hidden. My bad. Eventually disks could become cycle accurate bitstreams (HFE?) but for now OSI byte dumps are the used internally.

The disk timing update in a previous version has to do with the generation of the transmit data register empty signal in the simulated 6850 ACIA. Older versions waited until the transmission was finished (last bit clocked out) before generating that signal, now it is generated when a byte is moved from the 6850 input buffer to the shift register being clocked out as do real 6850s. This means that the CPU has more time to fill the input buffer before transmission stops which changes the balance of clock cycles spent waiting for the ACIA to become ready. It solved a bunch of weird emulated vs real timing issues, and David G's osifloppytest now shows correct 300/360 RPM values on WinOSI, as does Dos/65 speed test.
The CPU vs Floppy speed setting changes the rate at which virtual bits are clocked out. At a 1MHz CPU vs Floppy setting there are less CPU clocks before the TDE register is set, meaning less clock cycles before the end of disk is encountered. Some programs fail at 1MHz but are OK at 2MHz due to the # of cycles needed.

The file association problem with the last installer was due to the removal of the x86 WinOSI version on x64 systems -why have both? Unfortunately I forgot that the registry only contained references to WinOSI.exe not WinOSI64.exe, and corrected the problem a few hours later, however that was after your download. Now all versions are named WinOSI.exe, x86 or x64 depending on your system.

Other fixes include allowing some corrupted BASIC lines when decoding otherwise correct BASIC in memory as not all old disk images are 100% and glitches happen. Previously decoding would resume after corruption, meaning the start of a program could be ignored. Simulated key presses (used with PASTE operations) were configured to work better on OS65D, they were a bit too fast before and characters were dropped. Custom keymaps are now reloaded on emulator restart! Line printer output works for OS65D3.2 and OS65D3.3 on C3/C4/C8 systems. Setting instruction breakpoints on the RESET vector target work. Lot of little things.
Hope this helps!

Bug reports, suggestions, etc. welcome!
-Mark