Coco 2 + Mantra Alice + Dragon 32/64

[EeDee]

If I had payed a little more attention to what @dshadoff had explained I'd have realised that the Dragon Core would also load tapes at double speed (CAS that is) and saved myself some time
Shame to lose that little wrinkle

[bluearcus]

It's kind of complicated; as far as I know there are 3 modes : always slow / always fast / fast but going slow when some addresses are used, probably I/O ones. But seen from the user, when turbo mode is on, it should appear fast all the time (cursor blinks faster) but the sound will not be higher pitched, stuff like that.

Feedback from the community reporting bugs and wrong behaviour of the core welcome.

A few notes about the clock speed setting behaviour on the real machines. More details in the SAM 74LS783 datasheet of course.

The three speed behaviours available from the SAM chip are slow, address-dependent, and fast.

They are an optimisation which is available based on the fact that the SAM interleaves CPU RAM access with the VDG chip automatically, and the RAM is on a separate sub-databus area to the other system components.

In slow mode, the main cycle part is used by the CPU and the back part of the cycle is used by the SAM to fetch VDG data and to transparently perform dynamic RAM refresh (for a short while on each line, outside of the picture area of the display).

In fast mode, the VDG accesses and refresh counter strobes are dropped entirely, so the whole cycle is used for the CPU.

In address-dependent mode, the fact that the RAM databus is behind a buffer is used to make the CPU run fast when accessing ROM and fast IO areas on the main bus, with simultaneous VDG access and refresh happening on the RAM sub-bus. Only when accessing RAM, or slow io areas does the clock drop back into standard speed to allow the 'half cycle for CPU, half for VDG/refresh' approach. This switching occurs on a cycle by cycle basis.

Because BASIC is in ROM (and the dead cycle FFFF address which we see on all instructions is also in the same class of 'fast' addresses) then we get between 1.5 and 2x speedup for BASIC, but a bit less for machine code in RAM on a real machine. In 64k mode, the whole address space minus some bit of the top 256byte page classes as 'slow' so speedup is very limited when running OS9 for example.

[theflynn49]

Please ignore this wrong request, it works too. OOpps sorry

Hello All.
The latest core (not released yet, but the source) is able to run NitrOS9 on CoCo2 and Dragon64, and OS9 level1 runs also on Dragon64. We wish we could test OS9 Level 1 version 1.2 on CoCo2, but we can't find it anywhere.
...
...

[Mistix33]

Excellent ressources! Many thanks I have a mass of informations to read now ..

[theflynn49]

Hello all !

It's my pleasure to announce the release of the RC5 version of CoCo2, i.e. CoCo2_20250207.rbf
coming from the hard work of shodge12, alanswx, Kathleen, and myself.

Here are the changes :
CoCo2_20250207 - 001 RC5
1: Recursion testing spreadsheet completed.
2: Updated MiSTer template
3: Added Daily Build Number. Note sys/build_num.tcl changed to add this functionality.
Updating the template in the future will need to restore this version to prevent
the loss of this functtion.
4: Changed back to Cycle accurate 09
5: Fixed Timer [The FDC cartridge does not generate a FIRQ when asserted. This was fixed..]
6: Double speed poke in the SAM via SAM registers coded. Video sync at high speed fixed
7: FDC changed to use system clk and divide to 8 Mhz changed to /6. FIRQ generation
for Dragon, qualified enabled only in Dragon configurations.
8: Fixed some incorrect menu subscript duplications
9: Added Cassette Save
10: Added minor delay to 1793 interrupt to fix dragon os9 problem. Also removed HALT from
dragon FDC.
11: Nitro OS9 working on CoCo & Dragon64.

To Do... (nothing yet)

It's already in the MiSTer update system.
Enjoy !

[EeDee]

Thanks for this update. As far as I can tell from the time I've spent it works very well, although I've not tried saving to tape as yet.
Is a Readme update possible as there is not one to speak of really and it may help some new to the Dragon 32/64.
Thank you @theflynn49 for picking up the baton and running with it and to @shodge12, @alanswx, @Kathleen and all other contributers.

[theflynn49]

I am being told that a RC6 is coming soon.

Warning : this new release needs external boot0.rom to boot3.rom files. You may find them in the releases directory.

Instructions to build them are in the readme.md file if needed.

Coming soon to your mister

The bold adventurer may have an early taste of it here : https://github.com/MiSTer-devel/CoCo2_M ... s/releases

[theflynn49]

Update - looks like your using the DIR command. So maybe I DIR and look for a .bas file?
I did not have a disk drive on my Dragons and even cassette tapes had a lot of different options to load them !

Yes, after you insert a dis, just do "DIR" If you get an error, it means the disk is not readable (could be a dragon one for example if you're running coco2) or the disk driver cartridge is not in (try hard reboot).

[EeDee]

Update - looks like your using the DIR command. So maybe I DIR and look for a .bas file?
I did not have a disk drive on my Dragons and even cassette tapes had a lot of different options to load them !

Yes, after you insert a dis, just do "DIR" If you get an error, it means the disk is not readable (could be a dragon one for example if you're running coco2) or the disk driver cartridge is not in (try hard reboot).

Hi @theflynn49, that comment was from @higgy

[theflynn49]

Update - looks like your using the DIR command. So maybe I DIR and look for a .bas file?
I did not have a disk drive on my Dragons and even cassette tapes had a lot of different options to load them !

Yes, after you insert a dis, just do "DIR" If you get an error, it means the disk is not readable (could be a dragon one for example if you're running coco2) or the disk driver cartridge is not in (try hard reboot).

Hi @theflynn49, that comment was from @higgy

Shame on me and my 15 seconds attention window time

[EeDee]

Has anyone managed to load a cartridge on the Dragon, apart from the disc interface that is? I have some with the .vdk extension but renaming them to .ccc or .rom does not work. Do they need converting? If so does anyone know the process?

[theflynn49]

Has anyone managed to load a cartridge on the Dragon, apart from the disc interface that is? I have some with the .vdk extension but renaming them to .ccc or .rom does not work. Do they need converting? If so does anyone know the process?

Cartridges work. Usually they are .rom files in zip archives. CoCo cartridges seem to work on dragon.

.vdk files are not cartridges but disk images. What you can do is converting them into .dsk files by doing this (on mister or any linux machine)
First dump the 4 first characters of the file :

Code: Select all

hexdump -C -n 4 Games_01.vdk                                                                                                                                                                                                                

00000000  64 6b 14 00                                       |dk..|                                                                                                                                                                                                             

00000004

The "14 00" that you see is the length of the vdk header in hexadecimal (but you have to exchange the 00 and the 14, so it makes 0014). 0x0014 is. 20 in decimal. We want to remove the 20 first characters of the VDK file to obtain the DSK file, and we can do that with the "tail" command, whom you need to pass the length you want to remove PLUS ONE for some reason ... ho well. BEWARE : the "+" sign is important, it means we want to keep all bytes but the 20 first, instead of keeping the 21 last.

Code: Select all

tail -c +21 Games_01.vdk > Games_01.dsk

Check that the file you get is exactly 20 bytes less that the .vdk (if not, you made something wrong) :

Code: Select all

ls -l Games_01.*
total 512
-rwxr-xr-x 1 root root 184320 Feb 17 09:46 Games_01.dsk
-rwxr-xr-x 1 root root 184340 Feb 17 09:30 Games_01.vdk

Most DSK files for Dragon should be 184320 bytes long anyway, which is a way to be confident in your operation.

Be careful with the syntax, linux is demanding about that.
Also I don't guarantee that you'll get a functional disk, some formats won't work.

[pgimeno]

If the length of the file is in the ballpark of 184xxx bytes, wouldn't it be a tad simpler to just use this?

Code: Select all

tail -c 184320 Games_01.vdk > Games_01.dsk

That is, copy the last 184,320 bytes to a new file. That would void the need for checking the header length. I doubt there are any disks with garbage after the file.

Also, I wonder how hard would it be to add support for that format in the core. It sounds fairly simple on first sight, but I don't know the format of the requests between main and the core so it might actually be harder than it appears.

[theflynn49]

@pgimeno Actually, I prefer to check the header size because some disk images are shorter than they should, and some working disks have a different size than 184320.

The problem with supporting VDK format in the core is that one sector over two, you need to read two 512-bytes MiSTer SD sectors to assemble the requested 256-bytes the core needs, because beginning of sectors are not aligned with SD ones anymore.

[EeDee]

Has anyone managed to load a cartridge on the Dragon, apart from the disc interface that is? I have some with the .vdk extension but renaming them to .ccc or .rom does not work. Do they need converting? If so does anyone know the process?

Cartridges work. Usually they are .rom files in zip archives. CoCo cartridges seem to work on dragon.

.vdk files are not cartridges but disk images. What you can do is converting them into .dsk files by doing this (on mister or any linux machine)
First dump the 4 first characters of the file :

Code: Select all

hexdump -C -n 4 Games_01.vdk                                                                                                                                                                                                                

00000000  64 6b 14 00                                       |dk..|                                                                                                                                                                                                             

00000004

The "14 00" that you see is the length of the vdk header in hexadecimal (but you have to exchange the 00 and the 14, so it makes 0014). 0x0014 is. 20 in decimal. We want to remove the 20 first characters of the VDK file to obtain the DSK file, and we can do that with the "tail" command, whom you need to pass the length you want to remove PLUS ONE for some reason ... ho well. BEWARE : the "+" sign is important, it means we want to keep all bytes but the 20 first, instead of keeping the 21 last.

Code: Select all

tail -c +21 Games_01.vdk > Games_01.dsk

Check that the file you get is exactly 20 bytes less that the .vdk (if not, you made something wrong) :

Code: Select all

ls -l Games_01.*
total 512
-rwxr-xr-x 1 root root 184320 Feb 17 09:46 Games_01.dsk
-rwxr-xr-x 1 root root 184340 Feb 17 09:30 Games_01.vdk

Most DSK files for Dragon should be 184320 bytes long anyway, which is a way to be confident in your operation.

Be careful with the syntax, linux is demanding about that.
Also I don't guarantee that you'll get a functional disk, some formats won't work.

Thanks for that explanation @theflynn49 you have pointed me in the right direction. Some, but not all, COCO cartridges do work so I now need to search out Dragon specific ones.
The .vdk's were in a Cartridge Rom folder hence my misunderstanding. You explained converting .vdk to .dsk earlier in the Thread (using @pgemino's suggested solution) and that was very useful indeed. Though I must say this explanation is more interesting.
@pgimeno's comment and your reply adds to the interest for me

[Chazzy]

Hello.
Canyon Climber has a very fast paced ticking sound while playing.
Also, the explosion effect after clearing the first area does not display properly.
Thanks.

[theflynn49]

@Chazzy Thank you for reporting this. For now it will be added to @Kathleen work, who is running regression tests on a large base of stuff.
Altho the sound effect seems normal to me, on the other end, the end explosion seems funny ...