Cassette tape based file options?

Discussion about other targets
stefano
Well known member
Posts: 1802
Joined: Mon Jul 16, 2007 7:39 pm

Re: Cassette tape based file options?

Post by stefano »

There should be something totally untested ready for tomorrow in the nightly build.
In my tests the code on the emulators just crashed, but I still can't say it is a bug in the new functions.
look at include/arch/mz.h for the fn declarations.
The tape_save() function is currently allocating the structure for the header block in the same position used by BASIC, which requires a bit of shifting of the -zorg position
stefano
Well known member
Posts: 1802
Joined: Mon Jul 16, 2007 7:39 pm

Re: Cassette tape based file options?

Post by stefano »

please wait until tomorrow, I'm fixing a coupe of bugs.
moreover I'm adding a workaround. I can't understand why it is necessary to store the block size and length in the default MONITOR location of the tape header but this makes MAME work.
With this workaround I succeeded in saving and loading back the game status of adv_a running it in an emulated Z80A.
stefano
Well known member
Posts: 1802
Joined: Mon Jul 16, 2007 7:39 pm

Re: Cassette tape based file options?

Post by stefano »

MZ700 checked ;)

.. the little bit of text interaction makes the native console preferrable to "-clib=ansi".
mz700_adva.jpg
You do not have the required permissions to view the files attached to this post.
Wysardry
Member
Posts: 10
Joined: Sun Sep 04, 2022 8:46 pm

Re: Cassette tape based file options?

Post by Wysardry »

Well done. I wouldn't have been able to find a solution so fast. :)
stefano wrote: Tue Sep 20, 2022 9:27 am I can't understand why it is necessary to store the block size and length in the default MONITOR location of the tape header but this makes MAME work.
A lot of what you're saying is going right over my head, but if I remember the process correctly from thirty years ago, the MZ-700 had two different load and save commands.

From the MONITOR you would type "L" to load a machine code program (including the BASIC interpreter).

From the BASIC command line you would type "LOAD" to load a BASIC program. IIRC you couldn't load machine code programs if BASIC was loaded (you had to reset the machine first).

From within a BASIC program, "ROPEN" and "WOPEN" were used to open a file for reading and writing data respectively, but there would be no way to access those commands from a machine code program.

So, if I'm understanding you correctly, it would make sense to store the block size and length in the MONITOR location of the tape header for a machine code program.
pjshumphreys
Member
Posts: 30
Joined: Sat Feb 06, 2021 2:32 pm

Re: Cassette tape based file options?

Post by pjshumphreys »

Yeah, this is amazing work. Congratulations =D This kind of thing is why I like working with z88dk so much.

The MZ-700 monitor rom loading and saving code appears to have hard coded references to IBUFE (10f0h) as well as SIZE and DTADR located a few bytes later. It's also a shame the monitor rom code can't be persuaded to load/save without printing text on screen with RST 18h. At least as far as I can see anyhow.

I've also taken a look at a (admittedly modified) disassembly of Sharp's BASIC SA-5510 at https://github.com/pdsmart/tranZPUter/b ... 0_TZFS.asm. The version there also contains references to same monitor entry points for tape LOADing and SAVEing that these new functions now invoke.

@Wysardry, do you have real hardware this could be tested with?
pjshumphreys
Member
Posts: 30
Joined: Sat Feb 06, 2021 2:32 pm

Re: Cassette tape based file options?

Post by pjshumphreys »

So, if I'm understanding you correctly, it would make sense to store the block size and length in the MONITOR location of the tape header for a machine code program.
My understanding is that these new functions will take care of putting the required data into the proper places for you. These new functions can be invoked just the same as any other C function that takes "char *" parameters for example.

The new functions are in the mz.h include header file: https://github.com/z88dk/z88dk/blob/mas ... /arch/mz.h .
Wysardry
Member
Posts: 10
Joined: Sun Sep 04, 2022 8:46 pm

Re: Cassette tape based file options?

Post by Wysardry »

pjshumphreys wrote: Tue Sep 20, 2022 11:03 pm @Wysardry, do you have real hardware this could be tested with?
I have an MZ-700 stored in my parents' loft, but that is 300 miles away and I'm not sure if it still works as AFAIK it hasn't been used in years.
pjshumphreys
Member
Posts: 30
Joined: Sat Feb 06, 2021 2:32 pm

Re: Cassette tape based file options?

Post by pjshumphreys »

I see some changes have been made to the code for other targets to load and save data from tape as part of https://github.com/z88dk/z88dk/issues/2085 . I've been using the tape loading and saving functionality for the spectrum and confirm the functionality still works fine for my usage.
stefano
Well known member
Posts: 1802
Joined: Mon Jul 16, 2007 7:39 pm

Re: Cassette tape based file options?

Post by stefano »

Good, the recent changes have also brought the support for the TS2068 back to life, we lost the banked ROM (EXROM) call function when we rearranged the startup CRT0 stubs.

I just extended the library to MSX and Spectravideo SVI.
I still haven't checked the standard file formats, but the dumb block transfers seem to be working properly.

msx_svi_tape.png
You do not have the required permissions to view the files attached to this post.
stefano
Well known member
Posts: 1802
Joined: Mon Jul 16, 2007 7:39 pm

Re: Cassette tape based file options?

Post by stefano »

A further bit related to the Sharp MZ.

>From within a BASIC program, "ROPEN" and "WOPEN" were used to open a file for reading and writing data respectively,
>but there would be no way to access those commands from a machine code program.

Actually there is a way, but we'd depend on the presence of that BASIC version.

Calling the monitor is a good compromise, because it will act as a software compatibility layer between the different MZ models, I suspect that even the MZ800's QuickDisk would work.

The display interaction is not ideal, but definitely it is something a programmer can deal with (e.g. erasing the screen before starting the LOAD/SAVE process).

The tape_save() function is still totally untested on the Sharp MZ, the MSX and the Spectravideo SVI.
For the record it simply does not exist on the ZX80 and ZX81, they had a too primitive LOAD command, so I took the opportunity for using a different modulation scheme.
stefano
Well known member
Posts: 1802
Joined: Mon Jul 16, 2007 7:39 pm

Re: Cassette tape based file options?

Post by stefano »

tape_save() can be improved.
At the moment bluemsx does not seem to gather a correct BSAVE format, the custom trick is OK.
Moreover the implementation varies depending on the output, msx and sharp mz expect a further parameter for the execution entry, I think I'll rename those function and add a macro for compatibility purposes.
pjshumphreys
Member
Posts: 30
Joined: Sat Feb 06, 2021 2:32 pm

Re: Cassette tape based file options?

Post by pjshumphreys »

Having tape routines for MSX/SVI machines is particularly nice as they seem more common machines than the Sharp ones. Presumably if there's SVI support the MSX routines will work with both MSX1 and MSX2(+) machines right?
stefano
Well known member
Posts: 1802
Joined: Mon Jul 16, 2007 7:39 pm

Re: Cassette tape based file options?

Post by stefano »

They're using the ROM entries.
In my information the MSX BIOS never changes between the different models, at least the main BIOS entries should be guaranteed.
The SVI has its own 'standard', providing a small jp table on top like several computers did at the time.
Being the MSX an evolution of the Spectravideo project, it is often easy to spot equivalent ROM entries and write the libraries once for both the standards.
stefano
Well known member
Posts: 1802
Joined: Mon Jul 16, 2007 7:39 pm

Re: Cassette tape based file options?

Post by stefano »

I just succeded in writing an hopefully working tape_save() implementation for SVI and MSX.
It accepts a declared address different than the actual one like the ZX Spectrum one but takes an extra parameter for the execution entry.
The output format is the BSAVE one.
It should be ROMable and depends on BIOS calls but doesn't rely on the BASIC routine.
The break detection is probably disabled.
cborn
Member
Posts: 139
Joined: Tue Oct 06, 2020 7:45 pm

Re: Cassette tape based file options?

Post by cborn »

In the time off writin C itself tapes were common, so i expect that some routines are avialable already.
On zx spectrum i am looking into some turbospeed software which is fastloading off tapes. most of that is just change a few standard values.
eg https://worldofspectrum.org/software?id=0015960

now another thing is that many systems have their own basic AND their own LOADER sounds, the solution for this is called BASICODE
https://github.com/robhagemans/basicode
https://worldofspectrum.org/infoseek?q=BASICODE
https://archive.org/search.php?query=Ba ... oftware%22
https://basicode.de/

the original tapes have a loading system for many computer types in their native coding
cborn
Member
Posts: 139
Joined: Tue Oct 06, 2020 7:45 pm

Re: Cassette tape based file options?

Post by cborn »

this is a complete WAVE file with some differnt basic loaders, if an old "podcast" aka radioprogram
http://www.cborn.nl/zxfiles/basicode2a- ... v+mono.wav
User avatar
dom
Well known member
Posts: 1692
Joined: Sun Jul 15, 2007 10:01 pm

Re: Cassette tape based file options?

Post by dom »

cborn wrote: Sun Oct 02, 2022 5:58 pmnow another thing is that many systems have their own basic AND their own LOADER sounds, the solution for this is called BASICODE
Well, that took me on a little bit of a memory scraping journey. I was sure I remember software being transmitted via either radio and/or tv. The radio memory seems to have been courtesy of Simon Goodwin - I grew up in the area covered by Radio Wyvern. But TV, I thought some software was transmitted after shutdown, however a casual search hasn't shown anything up yet.
stefano
Well known member
Posts: 1802
Joined: Mon Jul 16, 2007 7:39 pm

Re: Cassette tape based file options?

Post by stefano »

BASICODE was used mainly in the Netherlands, even if it was announced a bit everywhere in the world.
It consisted in two main ideas: a BASIC program has to be written guaranteeing the compatibility among all the machines, a fixed set of subroutines provided the compatibility layer, e.g. to clear the screen or position the cursor, and an universal audio modulation format.
A program, where the universal loader was supported, was encoded in ASCII and modulated with the KansasCity standard.
The Philips P2000, in example, needed a self built interface because the micro cassette player wasn't able to deal with it.
In my opinion, the kansas city is a good candidate for an universal audio stream, but I don't live it very much.
Surely it works also as an hardware interface over a simple serial port, but in any case we wouldn't encode it in ASCII as BASICODE did.
cborn
Member
Posts: 139
Joined: Tue Oct 06, 2020 7:45 pm

Re: Cassette tape based file options?

Post by cborn »

https://en.wikipedia.org/wiki/Kansas_City_standard
BASICODE is even mentioned.
they mention P2000 to need a special hardware. i mentioned such a thing for the raspberyypi from which the NEWER version have no longer a dedicated BEEP port... the soundport has changed. but that is off topic.
Timmy
Well known member
Posts: 269
Joined: Sat Mar 10, 2012 4:18 pm

Re: Cassette tape based file options?

Post by Timmy »

Basicode is a loading system to send and load BASIC programs, and we are doing machine code here.
Also anything that use basicode would have to use speed of the lowest common denominator, so that loading scheme cannot be fast.
The WoS archive used to have the Best Of Basicode compilations archived, but they forgot to put them back in the archive after the handover.
These archive is likely to be in Dutch though so they might not be useful to you.
stefano
Well known member
Posts: 1802
Joined: Mon Jul 16, 2007 7:39 pm

Re: Cassette tape based file options?

Post by stefano »

The easiest way to get an universal SAVE routine is reusing the code we already have, so I'm on a prototype to save data with the ZX Spectrum format relying on the sound library.

I named the 2 functions bit_save_block_zx() and bit_save_zx(), thus similar functions could be added to save in KCS (Kansas City Standard) or whatever else will arise in the future.
The routine will probably need a bit of tuning and target specific code adjustments, but I brought the delay parameters in "games.inc", to make it easier.
Post Reply