UEF/CSW support Atomulator

discussion of games, software, hardware & emulators relating to the Acorn Atom
User avatar
CMcDougall
Posts: 6058
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: UEF/CSW support Atomulator

Post by CMcDougall » Thu Feb 15, 2018 5:59 pm

^ where is blocks 8 to 10 :shock: :?

If as they all work on my Atom, could have a version for no two seconds gap, so a Turbo Atom loader :D , would of been good 37years ago! :lol:
ImageImageImage

User avatar
oss003
Posts: 2735
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: UEF/CSW support Atomulator

Post by oss003 » Thu Feb 15, 2018 6:00 pm

Dave, did you use my uploaded CSW file or did you create your own?

Kees

User avatar
hoglet
Posts: 7123
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: UEF/CSW support Atomulator

Post by hoglet » Thu Feb 15, 2018 6:01 pm

oss003 wrote:Dave, did you use my uploaded CSW file or did you create your own?
I used your uploaded file:
- KAMIKAZI-mono.csw

User avatar
CMcDougall
Posts: 6058
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: UEF/CSW support Atomulator

Post by CMcDougall » Thu Feb 15, 2018 7:16 pm

http://www.stardot.org.uk/forums/viewto ... 18#p194175
better use mine as straight from original WAV (after convert 2 times to standard WAV)
as Kees one is from ATM.
also mine does make a workable UEFhq
+ CSW loads into my Atom after BackToLife prog 8)
ImageImageImage

User avatar
vanekp
Posts: 539
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands
Contact:

Re: UEF/CSW support Atomulator

Post by vanekp » Thu Feb 15, 2018 7:19 pm

okay let us into the secret what switches/software you used to make a uef file :wink:

User avatar
CMcDougall
Posts: 6058
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: UEF/CSW support Atomulator

Post by CMcDougall » Thu Feb 15, 2018 7:33 pm

viewtopic.php?f=44&t=10803#p194330
same as this but without -w 0 180 -v on end
& from my CSW 8)
ImageImageImage

User avatar
oss003
Posts: 2735
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: UEF/CSW support Atomulator

Post by oss003 » Thu Feb 15, 2018 7:47 pm

Ok, the *CAT is ok now but I can't get a decent UEF file without writing errors.

The -w 180 0 is sometimes needed to shift the phase.
The -v is to disable the messages.

I could however create a working UEF file from Tony's WAV file, after converting it to 8 bit mono but the CSW file couldn't be used.

Greetings
Kees

User avatar
hoglet
Posts: 7123
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: UEF/CSW support Atomulator

Post by hoglet » Fri Feb 23, 2018 8:22 pm

I've eventually solved the mystery of why MakeUEF was having problems with my machine generated WAV and CSW files. It comes down to MakeUEF being incredibly fussy about some very minor details of the Atom tape format - much more so that the Atom is! It's a bit hard to know if this is by design or if it's just a bug, because as far as I know MakeUEF v2.3 is closed source.

I was able to resolve the Write Error by simply inverting the waveform (i.e. it seems MakeUEF expects the first pulse to be negative going).

But it still wasn't recognising the Atom tape blocks. What was interesting was:
- with -z 1 ATM no blocks were recognised
- with -z 1 8N1 non standard block were recognised (21 bytes of header followed by 256 bytes of data, which is actually correct)

Then I remembered reading that the Atom stop bit was slightly lengthened. Looking very carefully at a stop bit saved from real Atom it seems there there is one extra cycle, i.e. the stop bit is 9 cycles of 2400Hz, not 8 cycles. You can see this in the highlight bit below:
audacity1.png
So I fixed my ATM to WAV/CSW generation code to do the same, and now MakeUEF is happy:

Code: Select all

C:\Users\David Banks\Documents\tmp\MakeUEF-v2.3>MakeUEF -y 1 300 -z 1 ATM -i 01_KAMIKAZE.csw -w 0 180 -v
MakeUEF V2.3.

Command line:
-y 1 300 -z 1 ATM -i 01_KAMIKAZE.csw -w 0 180 -v

Date (D/M/Y) and time:
23/02/2018   19:16

Baud rate format changed to 300.
Calculating the mean baud rate ...
Expected baud rate is 1200.
The following block size is 21
Found :      KAMIKAZE 00
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 01
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 02
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 03
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 04
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 05
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 06
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 07
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 08
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 09
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 0A
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 0B
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 0C
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 0D
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 0E
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 0F
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 10
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 11
The following block size is 256
Atom data format data block written.
The following block size is 21
Found :      KAMIKAZE 12        Last block flag
The following block size is 256
Atom data format data block written.
Here's the resulting files, if anyone want to mess with them:
01_KAMIKAZE.zip
(207.4 KiB) Downloaded 10 times
Now, there still seems to be a minor issue with the UEF in Atomulator. It loads correctly, but when you *CAT you get the extra addresses:
atomulator1.png
This doesn't happen with the CSW file, so I think my WAV/CSW generation is in the clear. It also happens with an original Atom generated WAV file (converted to CSW then UEF).

The reason for the extra addresses in *CAT is that the length of the high tone between then header and the data has been extended. This makes the data block look like a second header. This is either a bug in Atomulator's UEF handling or a bug in MakeUEF. It should be easy to determine which using uefwalk.

Anyway, my plan is to spend a bit more time on this over the weekend and push an updated version of Atomulator that fixes some of these issues.

Dave
Last edited by hoglet on Sat Feb 24, 2018 11:39 am, edited 1 time in total.

User avatar
BigEd
Posts: 1831
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: UEF/CSW support Atomulator

Post by BigEd » Sat Feb 24, 2018 12:08 pm

Excellent sleuthing!

ThomasHarte
Posts: 458
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: UEF/CSW support Atomulator

Post by ThomasHarte » Sat Feb 24, 2018 3:25 pm

Follow-up question: is the UEF attempting to set phase? I've always thought the specification goes somewhat off the rails on that.

User avatar
hoglet
Posts: 7123
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: UEF/CSW support Atomulator

Post by hoglet » Sat Feb 24, 2018 6:08 pm

ThomasHarte wrote:Follow-up question: is the UEF attempting to set phase? I've always thought the specification goes somewhat off the rails on that.
I don't see any phase chunks (0x0115) in the UEF being generated by MakeUEF.

I've just been looking at the UEF handling in Atomulator, and there appear to be a couple of things possibly wrong.

First, when a UEF high tone chunk is encountered, the value in the UEF file for the number of cycles of high tone is ignored.

Code: Select all

	case 0x110:         /*High tone*/
		if (!infilenames)
			dcd();
		gzgetc(uef); gzgetc(uef);
		if (infilenames)
			inchunk = 0;
		return;
https://github.com/hoglet67/Atomulator/ ... uef.c#L172

And dcd() is using a hard coded value of 15000 half cycles, which is about 3 seconds:

Code: Select all

void dcd()
{
	hightone = 15000;
//        printf("High tone on\n");
}
https://github.com/hoglet67/Atomulator/ ... 255.c#L229

The reason *CAT is messing up is because the 0.5 seconds of high tone between the header and data block ends up as 3.0 seconds. You can actually hear this if you turn on the tape sounds and *CAT an UEF file.

Second, it looks like the high tape frequency is incorrect.

In the polltape() function in UEF mode, tapecyc is updated as follows:

Code: Select all

		tapecyc += 794;
		intone ^= 0x10;
https://github.com/hoglet67/Atomulator/ ... 255.c#L186

In the emulator, tapecyc is then decremented at 4 times the cycle rate, i.e. 4MHz.

If you work out the resulting frequency from this (4000000/(794*2)) you end up with 2518.9Hz. The real atom is 2403.7Hz.

So it seems like this constant should be 832, not 794.

Did Sarah write this code originally? I would love to know if there is a good reason for using 794 (before I break it!)

Dave

Post Reply