TF536 with CDTV - Page 5

Toni Wilen · 25 October 2020, 13:43

Mostly done now, here is some instructions if you think this helps to debug/test this situation.

Two new options:

Expansion panel 24-bit DMA capable controllers have extra checkbox: 24-bit DMA. Unticked = full 32-bit address space is supported, ticked = upper 8 bits of address are masked out. Previously some DMA controllers had hardwired 24-bit limit, some didn't have it. (CDTV: Select CDTV DMAC and make sure checkbox is ticked to emulate real world CDTV)

RAM panel: Z2/Z3 RAM boards have DMA capable checkbox. Not ticked = DMA reads return ones only, writes are ignored. Other RAM types only have config file support: find RAM banks' "*_size" config entry and add new entry "*_options=nodma=true" (for example "bogomem_options=nodma=true") to make RAM bank not DMA capable. (Note that this does not affect chipset DMA, only expansion DMA capable controllers). This emulates situation where accelerator has RAM inside first 16M but memory is not DMA capable. (In real world this situation can cause ram corruption, random hangs etc..)

jotd · 25 October 2020, 15:03

thanks Toni. That will be super helpful to simulate the TF since the "addmem" fix that you suggested first doesn't emulate TF behaviour properly, and we could not test the patched rom with that, because the non-patched rom would work.

Are the changes available in a new beta already?

... just when you thought Winuae had already all the features....

alexh · 25 October 2020, 16:50

Quote:

Originally Posted by jotd

Are the changes available in a new beta already?

Looks like it.

Toni Wilen · 25 October 2020, 16:53

Yes, https://download.abime.net/winuae/files/b/winuae.7z has been updated.

"All" features can never be fully implemented!

jotd · 25 October 2020, 17:41

Thanks Toni. Unticking "dma capable" on Z2 ram makes "non-dos disk in drive 1" which means that the ROM allocates wrong memory type => WinUAE now makes it possible to test the new ROM!

But problem is even with the patched ROM (using the offsets alexh provided) it doesn't work.

I suppose that there are some missing AllocMem calls. I'm going to disassemble the extended rom to find them if I can

bartekmalysz · 25 October 2020, 17:50

I'm sorry I have nothing to contribute here, but thanks for the amazing job for the cdtv community!

jotd · 25 October 2020, 18:10

I've traced the allocmem calls that the extended rom does, and all extended ROM calls to AllocMem during the boot are properly redirected to chipmem.

There are one or 2 possible allocs without chipmem flag, but they're not triggered. So I'm kind of stuck...

Came to the same conclusions as there https://www.exxoshost.co.uk/forum/vi...tart=30#p23329

> patched all those locations and no joy. Wonder if the main KS alloc's any ram for disk buffers early on.

Toni Wilen · 25 October 2020, 18:18

Are you attempting to make HD (connected to CDTV SCSI adapter) or CDTV CD to work without DMA capable fast RAM?

HD is probably quite difficult because destination address can come from application directly or from used filesystem.

CD probably is not that difficult because AFAIK CDFS always use temp buffer where data is read first. (I guess because CDTV CD DMA can return more data than was requested)

jotd · 25 October 2020, 18:35

Yeah, I was trying to boot from HD with Z2 capable RAM. So looking for memory allocations in extended ROM is probably not enough.

The "ideal" CDTV system should boot from HD with non DMA capable fast RAM.

My WinUAE config uses SCSI so it's probably not compliant with TF, and I can't even check for CD because HD fails as Toni noted.

The original requirement was (just): make CD work from CDTV with TF as asked here https://retrocomputing.stackexchange...to-cdtv-cd-rom

Quote:

My setup is CDTV, KS3.1, TF536 50mhz, MMU, 64MB RAM, SD2IDE, ClassicWB ADVSP. This all works okay and stable with disabled extended rom, but I would love to have native/emulated access to built in CDROM.

The original idea was to extract devices from extended ROMs, patch them for chipmem and don't use extended ROM.

Toni Wilen · 25 October 2020, 18:45

Quote:

Originally Posted by jotd

Yeah, I was trying to boot from HD with Z2 capable RAM. So looking for memory allocations in extended ROM is probably not enough..

It can't be simply patched. At least device driver's CMD_READ and CMD_WRITE would need rewrite to always use chip ram buffers. (but because CDTV scsi.device has 1G limit, direct scsi is needed and buffering that is much more complex..)

But modified pfs3aio should be able to handle this situation, it has code that handles mismatched dma mask and uses temporary ram buffers. It might even work already if you set partition's mask value to chip ram only (0x1fffff).

It still needs device driver patch because buffers used for parsing partition table must not be allocated from fast ram.

bartekmalysz · 25 October 2020, 19:16

Quote:

Originally Posted by jotd

The original requirement was (just): make CD work from CDTV with TF as asked here https://retrocomputing.stackexchange...to-cdtv-cd-rom

Yes, the only thing I dream of is to have working CDrom under workbench when TF is installed, doesn't have to boot from it though.

alexh · 25 October 2020, 20:35

Quote:

Originally Posted by jotd

My WinUAE config uses SCSI so it's probably not compliant with TF536, and I can't even check for CD because HD fails as Toni noted.

The TF536 almost certainly implements a Gayle like IDE interface at the correct addresses so that the standard Kickstart IDE driver works.

Booting from a SCSI HDD connected to the CDTV SCSI controller would be a nice to have, I believe most TF536 users will only be using and booting from on-board IDE.

And while booting from CD would be a nice to have, I think just using CD in Workbench is the goal.

utri007 · 25 October 2020, 22:05

Quote:

Originally Posted by alexh

Booting from a SCSI HDD connected to the CDTV SCSI controller would be a nice to have, I believe most TF536 users will only be using and booting from on-board IDE.

And while booting from CD would be a nice to have, I think just using CD in Workbench is the goal.

this is how I think also.

jotd · 25 October 2020, 22:15

The aim of the TF is to convert an old machine to a hard drive + memory powered machine.

The hardware of the CDTV is specific, and the software that supports it hasn't been designed for non-DMA accessible memory. As Toni noted, it's not going to be a piece of cake to support SCSI or even CD-ROM (which may be a problem since a lot of CDTV titles don't have whdload support. Working on a few ones, but I generally have more luck with CD32 titles)

alexh · 25 October 2020, 22:24

Thanks very much for all your help. I guess the only way forward is to re-source some of the modules in Kickstart / Extended and re-code. Which won't be easy as AmigaOS device drivers are devilishly complicated.

TF did get somewhere re-sourcing cdtv.device (which I have) but sounds like it is more than just this one driver.

jotd · 25 October 2020, 22:33

note that some people (*cough*) have a copy of all Amiga ROM source code. But even with the source it's not easy.

I remember Toni noting that the hardware of the CDTV can deliver "cooked" CD sectors (means completely decoded as opposed to CD32 hardware). So a cd device could safely (at the time) assume that the target memory is DMA-reachable and write the data directly into it.

So it may be more than a problem of memory allocation. All programs passing a fast memory buffer would potentially fail. A big rewrite of the CMD_READ / filesystem command would be required to use a temp chipmem buffer & copy to final destination afterwards.

Why not just using CD ISO imaged mounted via SimCD on TF IDE? Earok did a superb job on TF CD32 with his latest CD including Simon the sorcerer and other impossible titles to adapt to whdload

I promise I'll focus on adapting CDTV exclusive titles for whdload. NeoHippie already provided me a ton of those.

utri007 · 25 October 2020, 23:19

Quote:

Originally Posted by jotd

Why not just using CD ISO imaged mounted via SimCD on TF IDE? Earok did a superb job on TF CD32 with his latest CD including Simon the sorcerer and other impossible titles to adapt to whdload

Some how that would just destroy my interest to TF536. CDTV just need to have working CD drive, if not then rather without a accelerator. I do have several other Amigas, but CDTV is only ECS machine wich interest me, mainly because "it has wife's aproval to living room".

Wondering what is still missing what Stephen had?

bartekmalysz · 25 October 2020, 23:38

Quote:

Originally Posted by utri007

... mainly because "it has wife's aproval to living room".

same

utri007 · 31 October 2020, 00:38

Could this solve problem? http://aminet.net/package/util/boot/KillCD0

KillCD0 (<- with a ZERO) is a small tool that can be used to kill CD0: on
a CDTV, A570 or CD32 so you can mount a new one with another filesystem
i.e. AmiCDFS or CacheCDFS from OS 3.9.

Run it early startup, even before setpatch?

I read doc and this could indeed be a solution as CDTV can boot from TF536 hard drive. Early on startup sequence "c:KillCD0 cd0" and mount it again with included CD0 file. It just needs to be modified to use chip men as a cache. It is also interesting, that CDTV.device can be used with other CD filesystems.

bartekmalysz · 31 October 2020, 17:17

I have a rom burner, all the soft and some more knowledge this time. Will be burning and testings roms tomorrow along with different soft and settings.

25 October 2020, 22:33	#96
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,172	note that some people (cough) have a copy of all Amiga ROM source code. But even with the source it's not easy. I remember Toni noting that the hardware of the CDTV can deliver "cooked" CD sectors (means completely decoded as opposed to CD32 hardware). So a cd device could safely (at the time) assume that the target memory is DMA-reachable and write the data directly into it. So it may be more than a problem of memory allocation. All programs passing a fast memory buffer would potentially fail. A big rewrite of the CMD_READ / filesystem command would be required to use a temp chipmem buffer & copy to final destination afterwards. Why not just using CD ISO imaged mounted via SimCD on TF IDE? Earok did a superb job on TF CD32 with his latest CD including Simon the sorcerer and other impossible titles to adapt to whdload I promise I'll focus on adapting CDTV exclusive titles for whdload. NeoHippie already provided me a ton of those. Last edited by jotd; 25 October 2020 at 22:39.

31 October 2020, 00:38	#99
utri007 mä vaan Join Date: Nov 2001 Location: Finland Posts: 1,653	Could this solve problem? http://aminet.net/package/util/boot/KillCD0 KillCD0 (<- with a ZERO) is a small tool that can be used to kill CD0: on a CDTV, A570 or CD32 so you can mount a new one with another filesystem i.e. AmiCDFS or CacheCDFS from OS 3.9. Run it early startup, even before setpatch? I read doc and this could indeed be a solution as CDTV can boot from TF536 hard drive. Early on startup sequence "c:KillCD0 cd0" and mount it again with included CD0 file. It just needs to be modified to use chip men as a cache. It is also interesting, that CDTV.device can be used with other CD filesystems. Last edited by utri007; 31 October 2020 at 01:16.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
TF536-Amiga 2000 REV 6.3,Can't get it to work	mark8564	support.Hardware	2	24 July 2020 07:25
WANTED - CDTV Keyboard & some CDTV parts	Dougal	MarketPlace	0	23 May 2015 01:02
WTB: CDTV laser, or CDTV drive, or CDTV	chiark	MarketPlace	15	09 February 2010 11:04
WTB: CDTV case / faulty CDTV / dead or alive	chiark	MarketPlace	7	26 September 2009 00:07
EPIC working on WinUAE-CDTV, but not on a real CDTV	mk1	support.Games	8	23 March 2009 20:12

25 October 2020, 13:43	#81
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,507	Mostly done now, here is some instructions if you think this helps to debug/test this situation. Two new options: Expansion panel 24-bit DMA capable controllers have extra checkbox: 24-bit DMA. Unticked = full 32-bit address space is supported, ticked = upper 8 bits of address are masked out. Previously some DMA controllers had hardwired 24-bit limit, some didn't have it. (CDTV: Select CDTV DMAC and make sure checkbox is ticked to emulate real world CDTV) RAM panel: Z2/Z3 RAM boards have DMA capable checkbox. Not ticked = DMA reads return ones only, writes are ignored. Other RAM types only have config file support: find RAM banks' "_size" config entry and add new entry "_options=nodma=true" (for example "bogomem_options=nodma=true") to make RAM bank not DMA capable. (Note that this does not affect chipset DMA, only expansion DMA capable controllers). This emulates situation where accelerator has RAM inside first 16M but memory is not DMA capable. (In real world this situation can cause ram corruption, random hangs etc..)

25 October 2020, 15:03	#82
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,172	thanks Toni. That will be super helpful to simulate the TF since the "addmem" fix that you suggested first doesn't emulate TF behaviour properly, and we could not test the patched rom with that, because the non-patched rom would work. Are the changes available in a new beta already? ... just when you thought Winuae had already all the features....

25 October 2020, 16:53	#84
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,507	Yes, https://download.abime.net/winuae/files/b/winuae.7z has been updated. "All" features can never be fully implemented!

25 October 2020, 17:41	#85
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,172	Thanks Toni. Unticking "dma capable" on Z2 ram makes "non-dos disk in drive 1" which means that the ROM allocates wrong memory type => WinUAE now makes it possible to test the new ROM! But problem is even with the patched ROM (using the offsets alexh provided) it doesn't work. I suppose that there are some missing AllocMem calls. I'm going to disassemble the extended rom to find them if I can

25 October 2020, 17:50	#86
bartekmalysz Registered User Join Date: Oct 2020 Location: Northwich, UK Posts: 42	I'm sorry I have nothing to contribute here, but thanks for the amazing job for the cdtv community!

25 October 2020, 18:10	#87
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,172	I've traced the allocmem calls that the extended rom does, and all extended ROM calls to AllocMem during the boot are properly redirected to chipmem. There are one or 2 possible allocs without chipmem flag, but they're not triggered. So I'm kind of stuck... Came to the same conclusions as there https://www.exxoshost.co.uk/forum/vi...tart=30#p23329 > patched all those locations and no joy. Wonder if the main KS alloc's any ram for disk buffers early on.

25 October 2020, 18:18	#88
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,507	Are you attempting to make HD (connected to CDTV SCSI adapter) or CDTV CD to work without DMA capable fast RAM? HD is probably quite difficult because destination address can come from application directly or from used filesystem. CD probably is not that difficult because AFAIK CDFS always use temp buffer where data is read first. (I guess because CDTV CD DMA can return more data than was requested)

25 October 2020, 22:15	#94
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,172	The aim of the TF is to convert an old machine to a hard drive + memory powered machine. The hardware of the CDTV is specific, and the software that supports it hasn't been designed for non-DMA accessible memory. As Toni noted, it's not going to be a piece of cake to support SCSI or even CD-ROM (which may be a problem since a lot of CDTV titles don't have whdload support. Working on a few ones, but I generally have more luck with CD32 titles)

25 October 2020, 22:24	#95
alexh Thalion Webshrine Join Date: Jan 2004 Location: Oxford Posts: 14,342	Thanks very much for all your help. I guess the only way forward is to re-source some of the modules in Kickstart / Extended and re-code. Which won't be easy as AmigaOS device drivers are devilishly complicated. TF did get somewhere re-sourcing cdtv.device (which I have) but sounds like it is more than just this one driver.

31 October 2020, 17:17	#100
bartekmalysz Registered User Join Date: Oct 2020 Location: Northwich, UK Posts: 42	I have a rom burner, all the soft and some more knowledge this time. Will be burning and testings roms tomorrow along with different soft and settings.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)