It looks great and is probably more than nice cassette drive replacement to use.
That "cassette drive replacement" is also the thing that makes me feel that only very little of the full potential of this kind of hardware has now been used... Since SVI-3x8 has fully digital cassette input, I think that with this kind of combo where all analog stuff is removed it should be easy to remove 90% of the loading times as well... Add some automatic compression and practical loading times will diminish next to nothing... The sad thing is that taking development to this kind of direction is slow and boring task due to all coding & testing steps needed.
It looks great and is probably more than nice cassette drive replacement to use.
That "cassette drive replacement" is also the thing that makes me feel that only very little of the full potential of this kind of hardware has now been used... Since SVI-3x8 has fully digital cassette input, I think that with this kind of combo where all analog stuff is removed it should be easy to remove 90% of the loading times as well... Add some automatic compression and practical loading times will diminish next to nothing... The sad thing is that taking development to this kind of direction is slow and boring task due to all coding & testing steps needed.
It's very difficult and the limitations of the real hardware itself, even under emulation, come into play. I don't know about the SVI but with MSX the maximum baudrate is 3760 even for openMSX. For the Spectrum the files need special header data for it to be loaded faster than the baudrates specified in the TZX files. TSX files for the MSX can be morte problematic. Aliens and Elite I have managed to get loading at 2400 baud but you cannot go any higher. Also when you're working with an Arduino 328p as with the CAS/TZXDuino projects memory and processor speed is limited. The Mega 2560 Pro has more memory but processing speed is the same.
Possibly with other microcontollers like the ESP32 it may be able to do more but it is using a sledgehammer to crack a peanut.
It's very difficult and the limitations of the real hardware itself, even under emulation, come into play. I don't know about the SVI
In SVI the BIOS supported speed is 1800bps IIRC
but with MSX the maximum baudrate is 3760 even for openMSX.
No, this limitation is caused by the stupid FSK encoding... Use better encoding and you could easily double that. OTLA would be good example of this, but unfortunately MSX version seems to suffer from some timing problems that tend to cause loading errors even on low speeds... On SVI there is no electronics between PPI and cassette port so connection is as direct as it can be. It should (at least in theory) enable much faster communication.
Also when you're working with an Arduino 328p as with the CAS/TZXDuino projects memory and processor speed is limited.
With software serial library Arduino 328p can communicate up to 115200 bps... but naturally I understand that all else takes time as well. As a protocol RS-232 is at least quite a bit better than "Kansas city standard" FSK that MSX cassettes are using, maybe this could be even a nice starting point.
I actually thought a bit more about this and found this MSX project:
https://hackaday.io/project/18552-joy232
This 75-byte program seems to be able to transfer RS-232 data @ 19200 bps speed using MSX joystick port. Since receiving data should not be much harder problem and SVI cassette port is similar from electronics point of view to MSX joystick port & CPU clock is same, I think this 19200 bps speed using RS-232 protocol on SVI cassette port should be very realistic.
With some more Googling I found this routine that should probably work after optimizing for SVI:
; ; CIN - input a character to C. ; ; HALFBT is the time for a half bit transition on the serial input ; line. It is calculated as follows: ; (BITTIM-101h)/2 +101h ; cin: ld b,9 ; bit count (start + 8 data) ci1: in a,(serial_port) ; read serial line and data_bit ; isolate serial bit jp nz,ci1 ; wait till serial data comes ld hl,(halfbt) ; get 1/2 bit time ci2: dec l jp nz,ci2 ; wait till middle of start bit dec h jp nz,ci2 ci3: ld hl,(bittim) ; bit time ci4: dec l jp nz,ci4 ; now wait one entire bit time dec h jp nz,ci4 in a,(serial_port) ; read serial character and data_bit ; isolate serial data jp z,ci6 ; j if data is 0 inc a ; now register A=serial data ci6: rra ; rotate it into carry dec b ; dec bit count jp z,ci5 ; j if last bit ld a,c ; this is where we assemble char rra ; rotate it into the character from carry ld c,a nop ; delay so timing matches that in output ; routine jp ci3 ; do next bit ci5: ret
Edit: Sorry for topic hijack.
It sounds like what you are talking about is something completely different to the idea behind Arduitape/CASDuino/TZXDuino.
The idea was for something easy to build and easy to use that simply uses the standard cassette inputs of 3.5mm for audio and 2.5mm for REM that was cheap.
What you're thinking of would use serial ports or joystick ports, which vary between computers so it would be less multipurpose.
EDIT: My fault for the topic hijack.
I'm interested in both this project and any ways people can think of improving my own.
The idea was for something easy to build and easy to use that simply uses the standard cassette inputs of 3.5mm for audio and 2.5mm for REM that was cheap.
No, no... That is exactly what I'm after... There would be no need to change connections on hardware side, but just load first the loader using already implemented routines and then just swap the communication protocol to something more efficient. (Still usíng the very same signal cable, just talking to it in different way after first file)
What you're thinking of would use serial ports or joystick ports, which vary between computers so it would be less multipurpose.
When I talk here about RS-232 I don't mean physical serial port with +-12v funny D-connectors etc. I just talk about the 1-wire / direction asynchronous communication protocol. -> Idea is same cable, different language.
It is true that this idea does not likely work nearly as well on MSX as the cassette port is implemented differently, but maybe on MSX this idea could still work on 4800bps or so... I just kind of felt in love with the idea that all of the wheel does not need to be invented again as we already have good, simple, asynchronous and well tested transfer protocol that just needs to be implemented.
As the first example of the idea was so horrible, I tried to calculate how the protocol could actually work on SVI... No idea if I got it right or not, but maybe worth a try?
; This program SHOULD read (Untested) 16-bytes from SVI-3x8 cassette port ; to #C000 when data is sent using RS-232 @ 19200 8N1 TTL-signal. DW BEGIN,END,BEGIN ORG #B000 BEGIN: LD HL,#C000 .LOOP CALL SERIAL_IN LD (HL),D INC L LD A,16 CP L JP NZ,.LOOP RET SERIAL_IN: LD D,1 .DATWAIT: IN A,(#98) ;12 ADD A,A ;8 JP NC,.DATWAIT ;11 LD B,6 ;8 .HALF DJNZ .HALF ;6X14+9 = 133 .LOOP LD B,8 ;8 === .ONE DJNZ .ONE ;X14+9 RL A ;9 ===138 LD A,0 ;8 IN A,(#98) ;12 Target: First 280, Nexts 186 ADD A,A ;8 RL D ;9 JP NC,.LOOP ;11 = 57+8X14=183 RET END:
@Romsey if you need anyone to test on real hardware I have CPCs, BBCs, Electrons, HX-10, NMS8235, happy to pay for the device. Happy to help.
I'm hoping to move to Australia soon along with my computers
@MSX4ever
Hi,
The unit costs $110 Australian and the SVI adapter cable $25 Australian - I had wanted to sell it at $80, but the current insanity gripping my country resulted in the postal service banning economy postal services from China, effectively closing the doors on my getting cost effective parts and limiting me to local sources. The only argument I can put up is that if someone actually wanted one it would be a one-off purchase anyway. This thing would have been finished 6 months ago if it wasn't for the postal service.
For Spectrum / MSX owners who don't have or use the 318/328 machines they obviously would not need to buy the adapter cable.
I currently have 30 PCBs on order from China and according to the manufacturer & tracking number they are in transit now - so (hopefully) I should see them in the next two weeks?
Posting items to international locations is also a big issue - there is one SVI-CAS still in the postal system after 1.5 month courtesy of how pathetic the Australian Postal Service really is. I've sold a handful of these to date and with a money back guarantee, but so far nobody wants to give their unit up.
@CASDunio
I've had a look at an arduino tape image player I found on the web (I think its a Maxduino) - I note that a timer is run and interrupts for every single level shift that occurs (unless I misunderstand the arduino code - I don't use arduino myself).
SV-CAS uses a very different technique that makes use of the 2560's hardware PWM capabilities together with signal output flipping and clock dividing machinations on the fly - this allows me to cut down on interrupt overheads massively and free up some of the micros time so it can drive a big display, touch screen, card reader, and play sound effects. I have several background tasks, one in particular reads ahead of the current point in the image buffer to adjust block parameters to their correct timings for the particular computer the unit is connected to - the adjustments are derived from profiles of each supported machine held internally by SVI-CAS, these profiles also tell it how to read standard tapes headers for that machine that may be inside an image.
From my testing of every TSX image I could find and all my many hundreds of accumulated CAS images I can't find a single working image that won't playback at 3600 for MSX (exceot for those that demand a custom baud rate of course) - the user manual documents the TSX results at the back, there were a handful of TSX images that I simply could not load into my MSX machines - even as WAVs, which puzzles me, and one image that would only work on 32k machines (Zaxxon) - I figure it was fussy about which slot RAM resided in.
Yes, the SVI-318/328 loading is sow - but so far I've found it 100% reliable with this unit.
As my video production skills are in the "toilet" so to speak, I'm hoping some one who buys one will do a video review at some stage.
MAXDuino is based on CAS/TZXDuino by myself and Andrew Beer. It's a noble attempt to join the two firmwares but in my opinion flawed on the 328p.
Most will work at 3600 baud but not necessarily benefit from it with TZXDuino. Elite and Aliens are really the main exceptions but they should work at 2400 baud.
Interesting about the ones that didn't and I would assume it's the difference between 64k MSXs and 32k+RAM or the SVI not being exactly 100% compatible.
Like I say.
I'm happy to help in any way and I have plenty of other systems to test on.
Just email me if you're interested.
I'm interested in both this project and any ways people can think of improving my own.
I checked your project and if you would add a switch like: Pin1=AMP IN, PIN2=EAR OUT, PIN3=AMP OUT ... then from hardware point of view your project could also support platforms like SVI-3x8 and C64 in the future. (Useless without software support & correct cable though)
Interesting about the ones that didn't and I would assume it's the difference between 64k MSXs and 32k+RAM or the SVI not being exactly 100% compatible.
You may like to check this page out:
https://www.msx.org/wiki/MSX_compatibility_problems