700/800 - are custom taperoutines common?

hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: 700/800 - are custom taperoutines common?

Post by hlide »

Jo Even wrote: Thu Apr 16, 2020 2:10 pm Or not, and fall back to the normal tape port.
If you plan to patch the monitor into DRAM, you cannot. Because when reading the BASIC this one is copying its own data in that area. So you will need to patch the specific ones to BASIC as well.
If you plan to have you own ROM, you still need to patch the BASIC but it is not sure to call the ones in ROM may be compatible enough - well I cannot say.
Jo Even
Site Admin
Posts: 152
Joined: Wed Jan 17, 2018 9:28 pm

Re: 700/800 - are custom taperoutines common?

Post by Jo Even »

If I don't patch the BASIC monitor it will use the normal tapeport, which the tapeemulator also supports. So in that case it will work at normal speed.
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: 700/800 - are custom taperoutines common?

Post by hlide »

ok, so your emulator has two ports: the expansion port and the tape port (internal or external?).
Jo Even
Site Admin
Posts: 152
Joined: Wed Jan 17, 2018 9:28 pm

Re: 700/800 - are custom taperoutines common?

Post by Jo Even »

Yes, my imaginary tape emulator has that.
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: 700/800 - are custom taperoutines common?

Post by hlide »

That's something I wanted to do with my existing project (mz-sd²cmt) but the AVR is not fast enough to handle memory bus unless you plan to use /halt, /busreq/ack or /wait to take the full control when needed. Suffice to say that you cannot handle a GUI, a SD reading and spying the memory or I/O bus to take CPU command in the same time. You must separate the moment you select a file to load (not listening the Z80 bus) and the moment where your device is listening to the Z80 bus to execute the CPU orders and probably the moment where the device may fully control the memory bus to fill DRAM while halting the CPU. In the end, I didn't elaborate something because I wanted a simple solution which didn't add chips (buffers, gal or cpld). But that would be an interesting project to continue.
User avatar
HajdaM
Posts: 6
Joined: Sun Apr 05, 2020 11:29 am

Re: 700/800 - are custom taperoutines common?

Post by HajdaM »

This is out of my scope, but I believe WAV player is somehow emulated on MZ-800 unicard, not sure if it's worth to look in it's source codes or ask author...
http://dzi.n.cz/8bit/mzuni/ (czech language)
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: 700/800 - are custom taperoutines common?

Post by hlide »

I have two of those beasts but the fact that I cannot access the source becomes a disapointment now. One instance. I was using VGA output but since I added a bigger CGROM to have both western and japanese fonts, VGA output is useless to display japanese games because the firmware is unable to offer the same possibility through its VGA implementation. There are several things I wish to do but without the source Unicard looks unfinished for me.
Jo Even
Site Admin
Posts: 152
Joined: Wed Jan 17, 2018 9:28 pm

Re: 700/800 - are custom taperoutines common?

Post by Jo Even »

hlide wrote: Thu Apr 16, 2020 8:00 pm That's something I wanted to do with my existing project (mz-sd²cmt) but the AVR is not fast enough to handle memory bus unless you plan to use /halt, /busreq/ack or /wait to take the full control when needed.
True, a faster microcontroller is needed. Something ARM-based, like the Teensy series, would be more than fast enough.
stefano
Posts: 6
Joined: Wed Feb 21, 2018 7:44 am

Re: 700/800 - are custom taperoutines common?

Post by stefano »

Sorry for jumping in late, I just discovered this topic.
This morning I'm pulling in a routine in z88dk able to load data stream in ZX Spectrum format.
The loader calibrates its speed by probing the monitor to understand whether it is running on a Sharp MZ-700 flavor or an earlier system.
In the latter case it assumes it is a 2Mhz CPU.
When run on the MZ800 the border effect is visible.
mz800_zxhdr.png
mz800_zxhdr.png (24.91 KiB) Viewed 3135 times
mz800_zxdata.png
mz800_zxdata.png (25.13 KiB) Viewed 3135 times

The possible "level up", after this concept, is to borrow the "extra turbo" loader I prepared for the ZXSpectrum on z88dk-appmake.
It is a one-way tool which prepares a specially encoded audio stream with 3 levels, thus '1', '0', and 'ESCape'.
When the 'escape' sync is met, the loader boosts at byte level, e.g. repeating the last received byte.
Consider it a kind of RLE compression decoding at runtime. Obviously the original audio stream was prepared on a PC, which can predict the future data sequences while crafting the audio file, which means that a corresponding SAVE command would be rather complex.
Post Reply