TF536 with CDTV

[bartekmalysz]

@utri007 not sure what needs to be done with startup sequence, I used your settings with replaced files, it boots to WB, but no CD0 device is shown, nor you cannot access it from the shell.

When you enable extended rom it goes back to 8000000B.

What is it you want me to try with the loadmodule? And please explain, is the goal here to let it boot from extended rom, unload it and replace with the extracted ones? What is the method here and why?

https://imgur.com/a/IMKafSB

[bartekmalysz]

Look, I have this ROM flashing development card I can donate, because I have no idea how to get this done. One thing though, it has to he open source.


It allows you to update rom without burning it, goes from floppy
https://imgur.com/a/NBfwo7B

[utri007]

Originally Posted by bartekmalysz

@utri007 not sure what needs to be done with startup sequence, I used your settings with replaced files, it boots to WB, but no CD0 device is shown, nor you cannot access it from the shell.

When you enable extended rom it goes back to 8000000B.

What is it you want me to try with the loadmodule? And please explain, is the goal here to let it boot from extended rom, unload it and replace with the extracted ones? What is the method here and why?

https://imgur.com/a/IMKafSB

What is location of CDTV.device and cdfs.library when you tried WITHOUT extended roms?

They should be :

System:devs/dosdrivers/cd0
System:devs/cdtv.device
System:L/cdfs.library

Goal of this is force CD-drive to use CHIP ram only and load needed drivers from hard drive.

About loadmodule command, you really need read it's manual.

Usually loadmodule command is used to load updated rom modules, over existing one. In this case we use it to remove them with remove swicth. This way you should be able to boot even when extended roms are enabled.



Wondering what else tools could be usefull to this MMULib? But I ques cdtv.device doesn't use MMU, because then there wouldn't be a problem. Could MuGuardianAngel solve this, it part of MMUlib archive?

[alexh]

I thought there might be enough information in the CDTV thread over at exxos to patch the ROM rather than require the firmware which patches on the fly?

viewtopic.php?f=76&t=1951&start=30#p23329

If I am reading this thread correctly, TF is talking about one memory location (0xF38706) which according to the Amiga Memory MAP documentation is in the CDTV Extended ROM. TF says this location is part of cdfs.library v24.9 and in particular an allocmem with the parameters "MEMF_CLEAR | MEMF_PUBLIC".

So that address should be offset 0x38706 into an Extended CDTV ROM file and I would expect the value should be : MEMF_PUBLIC|MEMF_CLEAR = $00010001 (I got the constant values for MEMF_PUBLIC and MEMF_CLEAR from a quick google)

If I look into the Extended ROM v2.30 file with a HEX editor I see starting at @ 0x38704-$0x38706 is the value $00010001

Now I am not an AmigaOS programmer but reading the thread and inferring what is going on I think the idea TF had was to patch the data being read from this address on the fly from MEMF_PUBLIC ($00000001) to MEMF_CHIP ($00000002) to make cdfs.device work with TF536 with FASTRAM fitted.

So if you change the data at the ROM location 0x38706 to $0002 that could be the fix?

The address location for this code will be different for Extended ROM v2.7 or v1.0

[utri007]

Originally Posted by alexh

I thought there might be enough information in the CDTV thread over at exxos to patch the ROM rather than require the firmware which patches on the fly?

viewtopic.php?f=76&t=1951&start=30#p23329

If I am reading this thread correctly, TF is talking about one memory location (0xF38706) which according to the Amiga Memory MAP documentation is in the CDTV Extended ROM. TF says this location is part of cdfs.device and in particular an allocmem with the parameters "MEMF_CLEAR | MEMF_PUBLIC".

So that address should be offset 0x38706 into an Extended CDTV ROM file and I would expect the value should be : MEMF_PUBLIC|MEMF_CLEAR = $00010001 (I got the constant values for MEMF_PUBLIC and MEMF_CLEAR from a quick google)

If I look into the Extended ROM v2.30 file with a HEX editor I see starting at @ 0x38704-$0x38706 is the value $00010001

Now I am not an AmigaOS programmer but reading the thread and inferring what is going on I think the idea TF had was to patch the data being read from this address on the fly from MEMF_PUBLIC ($00000001) to MEMF_CHIP ($00000002) to make cdfs.device work with TF536 with FASTRAM fitted.

So if you change the data at the ROM location 0x38706 to $0002 that could be the fix?

The address location for this code will be different for Extended ROM v2.7 or v1.0

That would be nice, know anyone who could patch it?

[bartekmalysz]

Sounds it may be as simple as finding someone with very good understanding of ancient computing technology, 68k architecture and AmigaOS system knowledge willing to do it for free or a small fee

[jotd]

why not just patch the extracted cdfs.device file and disable the extended ROM? Should be much simpler

[Don_Adan]

Originally Posted by jotd

why not just patch the extracted cdfs.device file and disable the extended ROM? Should be much simpler

How? It works at absolute addresses. The easiest way is fix ROM and burn new ROM, one change, maybe two changes, if extended CDTV ROM has checksum.

[jotd]

or maybe without burning a new rom only by software, patch allocmem to block fast memory (anymem from http://aminet.net/util/boot/AnyMEM_v14.lha mentionned in http://eab.abime.net/showthread.php?t=67684) / load the cd module or mount the CD driver / remove the allocmem patch

[utri007]

Originally Posted by jotd

or maybe without burning a new rom only by software, patch allocmem to block fast memory (anymem from http://aminet.net/util/boot/AnyMEM_v14.lha mentionned in http://eab.abime.net/showthread.php?t=67684) / load the cd module or mount the CD driver / remove the allocmem patch

OK, you suggest that if CHIP ram only would be needed just when mounti CD0? After that AnyMEM could be removed?

Some programs requst Fast RAM specificly, these programs will fail on a Chip RAM only Amiga. AnyMEM will make sure that this wont happen.

I don't have TF536 yet, so I can't test these. Would MuGuardianAngl patch illeagal memory access also in this case? http://aminet.net/package/dev/debug/MuGuardianAngl


PS. it is cdtv.device and filesystem is cdfs.library. CDTV.device is supposed to be problem.

[Don_Adan]

Originally Posted by jotd

or maybe without burning a new rom only by software, patch allocmem to block fast memory (anymem from http://aminet.net/util/boot/AnyMEM_v14.lha mentionned in http://eab.abime.net/showthread.php?t=67684) / load the cd module or mount the CD driver / remove the allocmem patch

I dont mean it will be works ok. If i remember right CD is initialized via CDTV ROM when CDTV boot. Then external programs/patches are useles, because will be executed too late. Perhaps the easiest way is check this on WinUAE. Choose CDTV with fast memory.

[jotd]

Don you may be right. But I think OP wanted to disable extended rom and only boot on IDE HD from normal rom + ripped cdtv.device + cdfs.device.

[utri007]

Originally Posted by jotd

Don you may be right. But I think OP wanted to disable extended rom and only boot on IDE HD from normal rom + ripped cdtv.device + cdfs.device.

That is not a case, we just want to get CD-drive work with accelerator. I have also a CDTV and I'll get TF536 hopefully soon.

There is several acceptable ways, but disabling extended roms would be worst case scenario, but accepteable if CD-drive works that way.

[Don_Adan]

If TF turbo has AutoConfig, then perhaps exist other solution too. Fast RAM must have lower priority than chip RAM, and Amiga CDTV will be allocated at first chip ram, if available. This is perhaps the easiest way, and maybe can be selectable from control tool.

[alexh]

Originally Posted by utri007

That would be nice, know anyone who could patch it?

You? The exact details are in my post

TF has replied albeit cryptically

Originally Posted by TF

Guys i cant release a patched ROM as its still under copyright. I supposed i could make a script to patch a rom with python or something. All the information is already here.

Here could mean my post, that one byte, or it could mean the other patches throughout his thread on exxos as he searched without success to make CD booting work too.

Someone try it? I don't have a TF536 nor the relocator. I have a CDTV, ROMs and a burner but UK only.

I'm fairly sure that changing that one byte in the Extended ROM, burning a new ROM will allow the TF536 with FASTRAM installed to boot and the CD drive to work in workbench.

Should be possible to try in WinUAE (can you select a CDTV with 030 and 32-bit autoconfig FASTRAM?)

[jotd]

I've created a python script which changes memory type for 2.3 ROM

https://github.com/jotd666/amiga68kt...e/master/tools

patch_cdtv_rom.py

There are no checksums, I could boot a game with this patched rom. I haven't tested on a TF config, only winuae standard CDTV, no fast memory and all.

[alexh]

Originally Posted by jotd

I've created a python script which
patch_cdtv_rom.py

Thanks, should help those who want to try this but are not comfortable with hexedit.

If anyone is interested, this script verifies the input file is a valid 2.30 extended ROM (using MD5 hash) and then patches the one 16-bit location that TF found from 0x0001 to 0x0002.

It might need another hash because there are two v2.30 extended ROMs (the original which comes from the A570 and a patched one by Cloanto, which removes the red screen if a floppy disk drive is not attached)

And thanks for testing. It proves that this change is ok for normal CDTV operation when the TF536 is disabled (which you would expect if this address really is what TF says it is.)

[jotd]

if you know another valid rom hash please provide it. Is it necessary to add patch support for 1.0 ?

[utri007]

Originally Posted by jotd

Is it necessary to add patch support for 1.0 ?

Thanks guys.

I think that is safe to suppose, that TF536 or other accelerator users has at least 2.7. Would that be possible, with that there is no red tinted screen.

bartekmalysz could you test this? What is required to run that python script?

[alexh]

Originally Posted by utri007

TF536 or other accelerator users will have at least 2.07 Would that be possible, with that there is no red tinted screen.

It is possible to use v2.07 because cdfs.device didn't change between v2.07 and v2.30. You just need to know the address to patch, which you can get using RomSplit/Remus by Doobrey (Many thanks to him for all his hard work over the years)

2.7:
$000000B6 - $00003BBC (00003B06) exec.library , exec 37.201 (28.1.92)
$00003BBC - $00003BD6 (0000001A) alert.hook , alert.hook
$00003CA0 - $0000541A (0000177A) cdtv.device , cdtv 35.12 (28.1.92)
$00005428 - $00005516 (000000EE) setpatch , setpatch 37.3 (31.10.91)
$0000558C - $000087EC (00003260) A590/A2091 IORequest handler , SCSI/XT driver by SMB (01.05.89)
$00008822 - $000091C8 (000009A6) utility.library , utility 37.3 (13.2.91)
$0000920C - $00009830 (00000624) battclock.resource , battclock 38.1 (10.3.91)
$0000983C - $0000A47E (00000C42) debox.library , debox 1.8 (16.10.91)
$0000A48E - $00035080 (0002ABF2) playerprefs.library , playerprefs 2.2 (7.11.91)
$0003508C - $00038468 (000033DC) cdfs.library , cdfs 24.9 (22.10.91)
$000386D4 - $0003A4BA (00001DE6) cdg.library , cdg 2.10 (3.2.92)
$0003A546 - $0003ADCE (0000088 bookmark.device , bookmark 6.6 (31.1.92)
$0003ADD8 - $0003C092 (000012BA) CDTV Bootstrap , cdstrap 9.7 (12.11.91)
13 residents found.

2.30:
$000000B6 - $00003BBC (00003B06) exec.library , exec 37.201 (28.1.92)
$00003BBC - $00003BD6 (0000001A) alert.hook , alert.hook
$00003C9C - $00005410 (00001774) cdtv.device , cdtv 35.14 (29.2.92)
$00005484 - $000086E4 (00003260) A590/A2091 IORequest handler , SCSI/XT driver by SMB (01.05.89)
$00008712 - $000090B8 (000009A6) utility.library , utility 37.3 (13.2.91)
$000090F0 - $000096AE (000005BE) kludges , kludges 37.11 (14.5.92)
$000096B2 - $000096EA (0000003 A690ID , a690 2.6 (29.2.92)
$000096F0 - $00009D14 (00000624) battclock.resource , battclock 38.1 (10.3.91)
$00009D18 - $0000A95A (00000C42) debox.library , debox 1.8 (16.10.91)
$0000A966 - $0003553C (0002ABD6) playerprefs.library , playerprefs 2.2 (7.11.91)
$00035544 - $00038920 (000033DC) cdfs.library , cdfs 24.9 (22.10.91)
$00038B80 - $0003A966 (00001DE6) cdg.library , cdg 2.10 (3.2.92)
$0003A9E6 - $0003B26C (00000886) bookmark.device , book 6.7 (14.5.92)
$0003B270 - $0003C7D6 (00001566) CDTV Bootstrap , cdstrap 9.17 (14.5.92)

So the address to patch in v2.07 is $3824E (I confirmed this using a hex editor) (This is how I calculated it : $3824E = $38706 - ($35544-$3508C))

v2.07 has the MD5 HASH of D1145AB3A0F89340F94C9E734762C198

NOTE that v2.07 is older than v2.30.

I would recommend using the Cloanto v2.30 which has had the red screen patched.

I can't find the HASH for cloanto v2.30 (It is not on my version of AF) but the Cloanto website has it as having the CRC32 of A5A6ED15