Emulation questions

Discuss the games, programs, utilities... and vaporware!
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: Emulation questions

Post by @username@ » Sat Jan 03, 2015 2:39 am

While going through the posted listings for BASIC82/83, I noticed that Factory Flare-Up has a text file, warning

Attention: listings are not 100% correctly converted!

Well, my converter does it perfectly. I use the emulator, which in turn uses BASIC83 to decode and verify the data,
by simulated CLOAD, bit by bit.

To convert a wave to a CAS file takes no time, all you need to know is the pulse width for mark and space, or 1 and 0, and you're done.

You don't need to care about checksums, headers or whatever - let BASIC83 sort that out.

So attached is a working copy directly from the creatiVision emulator.

Yes it uses some interesting characters in the print statements - but that's fine - they are verified ok by VTL!

The game, well you decide :D
You do not have the required permissions to view the files attached to this post.
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Emulation questions

Post by MADrigal » Sat Jan 03, 2015 8:53 am

Thanks for the fix, @username@.

The conversion from WAV to TXT was made with the still very good "CvTape converter" by my long time friend, Giovanni Ortu. Unfortunately, the program is not perfect and sometimes it gets garbled data from the WAV files.

I have tried your listings (.bas version) on the "FunnyMu" emulator and they report a "Syntax Error" at line 5790.

So loaded the game (.cas version) onto the "creatiVision Emulator" and it worked fine. Then tried to LLIST the fflare3.cas into "printer.txt" file, so I suppose the listing should be correct.

But again, I try loading the "printer.txt" file on the "FunnyMu" emulator, and it prompts the "Syntax Error" at line 5790.

I can't verify if the data on line 5790 is correct, because it's a "print ....." with ascii characters. Not sure if there's some "invisible" char in there, causing the error.

There's an additional oddity. The "fflare3.bas" file included in your 7Z archive is 7,458 bytes long, whereas the one I get from the "cV Emulator" is 7,854 byte long. Any idea why?

I would love to update the "fflare.zip" file on the CVEmu website, but obviously I want to make sure that the file is 100% working. Thanks :)
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: Emulation questions

Post by @username@ » Sat Jan 03, 2015 12:14 pm

Ok, I'll say this again.

The program data was decoded and verified by BASIC83B

The source was the mono channel wave from here. The creatiVision emulator loads EXACTLY the same way as a real CV.

This means, that each bit has to be correct - or you will receive ERROR 00.

In the case of BASIC83, that means that what it decides is the packet header MUST be correct.

Each packet LRC also MUST be correct.

The EOS packets also MUST be correct.

To convert a wave file to a CAS is simply this. Count pulse width, where the pulse width exceeds a value, which is dependent on sample rate, output a 1 bit, otherwise output a 0 bit. If this is in error, extra 1s or extra 0s, it simply won't load.

There are control characters in the PRINT statements, does this confuse FunnyMu?

Again, the decoding is done by the original software - there is no external manipulation of the data.

Let me put the shoe on the other foot, can you explain why the creatiVision emulator works, and the combination of CVTAPE and FunnyMu don't?

You need to update your mindset.
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Emulation questions

Post by MADrigal » Sat Jan 03, 2015 12:54 pm

@username@ wrote:There are control characters in the PRINT statements, does this confuse FunnyMu?
Yes that's an option I didn't think of.
@username@ wrote:Again, the decoding is done by the original software - there is no external manipulation of the data.
Any idea why the fflare3.bas file on your archive has different size than the one I got through LLIST on the "creatiVision Emulator" ?
@username@ wrote:Let me put the shoe on the other foot, can you explain why the creatiVision emulator works, and the combination of CVTAPE and FunnyMu don't?
This has nothing to do with the listing coming from the CvTape program. It's about the FunnyMu reporting a "syntax error" when executing the "fflare3.bas" listing you uploaded. Maybe FunnyMu can't manage control characters.
@username@ wrote:You need to update your mindset.
Sorry I can't understand, would you kindly rephrase this?
User avatar
Mobsie
Posts: 708
Joined: Fri Jun 13, 2008 10:38 am
Location: Weinheim, Germany

Re: Emulation questions

Post by Mobsie » Sat Jan 03, 2015 4:04 pm

The new Version is Great, the Sound Engine is percect!
Sound amazing with my Tetris clone and the Maze Demo, the only CV Programms WHO use the soundchip like it should be used :D
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: Emulation questions

Post by @username@ » Sat Jan 03, 2015 4:56 pm

MADrigal wrote:There's an additional oddity. The "fflare3.bas" file included in your 7Z archive is 7,458 bytes long, whereas the one I get from the "cV Emulator" is 7,854 byte long. Any idea why?
Sure, you're on windows. It outputs an extra CR when it sees LF, so line endings become CR/CR/LF.

By update your mindset, I mean you need to start looking more at how we work today, not what we did 5 or more years ago.

CVTAPE, if we believe the UI, uses analogue algorithms, which is overkill on a very basic, single source file. If you switch the mindset to be more, how does an 8bit console load this - it all should become clear.

The console has no concept of carrier waves or sidebands or anything. It only knows on(1) or off(0). Where that pulse falls on the median is completely irrelevant. Thus decoding really is as simple as count the samples between the troughs. Very simple, and employed by most 8bit tape systems.

The actual code which does it is

Code: Select all

ROM:9ABB                 LDA     $D0
ROM:9ABD                 BNE     sub_9A92
ROM:9ABF                 STY     $DE
ROM:9AC1                 JSR     sub_9B3D
ROM:9AC4                 TYA
ROM:9AC5                 CLC
ROM:9AC6                 ADC     #$2F ; '/'
ROM:9AC8                 CMP     $DE
ROM:9ACA                 BCC     sub_9A92        ; Branch less than
ROM:9ACC                 TYA
ROM:9ACD                 SEC
ROM:9ACE                 SBC     #$2F ; '/'
ROM:9AD0                 CMP     $DE
ROM:9AD2                 BCS     sub_9A92        ; Branch greater than
ROM:9AD4                 CLC
ROM:9AD5                 LDA     $DD
ROM:9AD7                 ADC     $DE
ROM:9AD9                 STA     $DC
ROM:9ADB                 LSR     $DC
ROM:9ADD                 JSR     sub_9B32
ROM:9AE0                 BCC     sub_9A92        ; Branch less than
ROM:9AE2                 JSR     sub_9B32
ROM:9AE5                 BCS     sub_9A92        ; Branch greater than
ROM:9AE7                 JSR     sub_9B32
ROM:9AEA                 BCS     sub_9A92        ; Branch greater than
ROM:9AEC                 JSR     sub_9B32
ROM:9AEF                 BCC     sub_9A92        ; Branch less than
ROM:9AF1                 JSR     sub_9B32
ROM:9AF4                 BCC     sub_9A92        ; Branch less than
                                RTS
This is how the BASIC83 cartridge works out the pulse width. It averages it out in $DC to arrive at a mean distance between space and mark.
From $9ADD on in this listing, it's looking for the magic 10011 header mark. This is how it throws aways "noise" at the beginning of the tape.

Once the mean is calculated, it simply does

Code: Select all

ROM:9B32 sub_9B32:                               ; CODE XREF: sub_9A92+4Bp
ROM:9B32                                         ; sub_9A92+50p ...
ROM:9B32                 JSR     sub_9B3D
ROM:9B35                 CPY     $DC
ROM:9B37                 BCC     loc_9B3B
ROM:9B39                 SEC
ROM:9B3A                 RTS
ROM:9B3B ; ---------------------------------------------------------------------------
ROM:9B3B
ROM:9B3B loc_9B3B:                               ; CODE XREF: sub_9B32+5j
ROM:9B3B                 CLC
ROM:9B3C                 RTS
So compare the current pulse width to the mean width in $DC, and set the flag to 1 or 0.
To do the same with a wave file would be compare the current sample to the previous, is it of higher value, yes so rising edge, otherwise we are going down to a trough, keep counting till it rises again.

This is generic, it will work with CV, Salora, ZX Spectrum, C64 and so on. AM and FM don't come into it.
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: Emulation questions

Post by @username@ » Sat Jan 03, 2015 8:40 pm

This is the Laser 2001 BASIC 1 Introduction / Typewriter programs in both CAS and BAS format.
You do not have the required permissions to view the files attached to this post.
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Emulation questions

Post by MADrigal » Sun Jan 04, 2015 12:28 am

@username@ wrote:Sure, you're on windows. It outputs an extra CR when it sees LF, so line endings become CR/CR/LF.
This makes sense!
@username@ wrote:CVTAPE, if we believe the UI, uses analogue algorithms, which is overkill on a very basic, single source file. If you switch the mindset to be more, how does an 8bit console load this - it all should become clear.
Now I understand the routine, thanks.

From my memory, the CvTape works like this:
1. parses the whole wav file in search of the absolute peak
2. uses the "Threshold" value as the highest value giving a "zero" bit
3. parses the wav file again, in search of the first $13 value (00010011)
4. from that point, stacks bits in groups of 8 and then converts them into ascii code

You should consider that CvTape doesn't work in CreatiVision environment, but in Windows. It gets data from a WAV file and outputs into TXT format.

This means that it's up to the CvTape to parse every value of the WAV file (that is dealing with stereo/mono, absolute peaks, AM/FM and sample rate), join bits into ascii code, and then make them into a plain text file.

Obviously it is much more advantageous to use the cv BASIC to do the job, but at the time the CvTape was designed, we had no working emulator to extract the listings from WAV file. It was circa 2001 or 2002. And the CvTape has proved to be extremely useful for several years, all things considered. And I'm obviously grateful to Giovanni for developing it at his best. :)

Speaking of the FunnyMu limitation with "special characters", I think it's not a problem with the emulation routines, it must be a problem with the "import from TXT" routine, which I designed with Giovanni around 2007. Anyway I dont have any chance to update the emulator, so I believe I would try to convert part of the BASIC listing by changing a few "nasty" special characters into CHR(xx) calls in the PRINT statements.
I want to make sure that the workaround would be good to let me play the game on the FunnyMu.

I am obviously very interested in more updates from you, especially with regards to the BASIC listings. My role in the CV community has changed a lot over the years, and all I can do now is maintaining the best possible archive of files, including BASIC listings.
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: Emulation questions

Post by @username@ » Sun Jan 04, 2015 2:49 pm

One Armed Bandit correction.

Had GOT0 not GOTO.

As stated before, a CAS file is simply a bit dump by the emulator.

This means you can convert a CAS using SMBload utility to upload to a real machine.
You do not have the required permissions to view the files attached to this post.
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Emulation questions

Post by MADrigal » Sun Jan 04, 2015 10:08 pm

Got it. Thanks.
Post Reply