check this site, it is the best I found, the FC0-FC2 are present but not used by memory expansion unless I have to use them by myself, I will look into it. Unfortunately my mem is 8MB or nothing.
/OVR - what? how?
- Thread starter bebek
- Start date
- Replies 32
- Views 8275
check this site, it is the best I found, the FC0-FC2 are present but not used by memory expansion unless I have to use them by myself, I will look into it. Unfortunately my mem is 8MB or nothing.
For the schematics, download the full Amiga range from Aminet. The CD32 ones are crystal clear. 
Notice the huge size!
Notice the huge size!
bebek;154302 said:
Here is a simple hack you can try to hopefully* limit your memory expansion to less than 8 meg. Disconnect A23 and/or A22 from the memory board and jumper the memory boards A23 and/or A22 connector pin to GND. A23 grounded should give you 6 meg and A23 + A22 grounded should give you 2 meg. Let me know the results.
Normally, FC0-FC2 are recommended for address decoding the prevent the memory board from responding to CPU space cycles but under certain circumstances you may be able to get by without them.
* Hopefully this board doesn't have some kind of Auto Config logic which causes an expansion error.
Last edited:
skippy
New member
I've noticed if the CDROM ribbon (CN17) is disconnected there's NO boot delay before the Kickstart CD ANIM screen to suggest any cdrom device module(s) or [kickstart Gayle IDE] have failed query during early boot sequence. Maybe the cdrom is a totally custom independent unit. (nothing listed in the early boot menu.)
#So you're none the wiser if the cdrom unit is actually working until you go to use it. :huh:
"no spin, nothing" - It might be worth probing TP8 which is tied in with the main data lines to Akiko (CPU/System interface) -> 68000 -> 182-pin MCA edge connector. As from the schematics Akiko seems to be the primarily responsible for the CDROM interface.
As there's no IDE interface and a custom CDrom controller is tied into the aforementioned perhaps there's a conflict/violation from MCA with the presence of your RAM expansion sharing the same bus lines. (*buffered interface needed?)
I've tried to keep this "byte-size" <- pun. This is mainly what I recall from the earlier Amigas, slightly different for the CD32 I imagine with a 68020@14.3MHz.
The FC0-2 is part of the interrupt acknowledge process:
68K generates this function code if it requests an interrupt vector.
Option 1. Provide your own vector (RAM expansion hardware)
Option 2. Don't acknowledge the request and let CPU fetch autovector from the vector base table
Cycle type strobing process (LOW/HIGH 0|1 Bits)
#Function code lines:
FC0-2 (Signal operating state of CPU USER/Supervisor) the output distinguishes program references from data references.
= 68K - Data reference = WRITE
= 68K - Operands = READ (Except PC)
#Bus control lines:
+ AS (Asynchronous) Mode: (As you mentioned using)
1. CPU signals the request: Data bus strobes UDS (upper data)|LDS (lower data)| R/W (read or write byte/word using UDS/LDS) [D15-8 D7-0] AS (Addr$ strobe)
2. CPU then waits till memory informs data ready (DTACK = 0|LOW) DTACK tells CPU data received.DTACK is strobed by external AS memory after a write access to acknowledge that data has been taken over.
DTACK is generated immediately AFTER AS occurs (using remaining cycle).
If slower memory then set XRDY (0|LOW) (similar to DTACK) (sort of an external DTACK) overriding DTACK (1|HIGH) the CPU will then perform "wait states".
Thus AS mode adapts to speed of memory.
(You mentioned not using the following avenue)
+ Synchronous Mode: E (clock), VPA (Valid peripheral addr$ synchronous switch mode [set 0 external decoder]), VMA (CPU answers VPA w/ Valid memory addr$ = 0)
I don't know alot about the DSACK/bus on the 68020, but on the earlier models all except the DTACK, VPA, VMA, RES, HLT, BERR, E signals are buffered; whether this transcends/applicable to your GAL buffered idea.
I've briefly looked at the REV 3 schematic and it could well be you need buffer and use a decoder.
Could explore the DMA further to ensure the Address/Data bus and control signals are being handled/processed/acknowledged correctly by the CPU.
IE: RAM Expansion vs CDROM Bus Master access/privileges.
Well done with your project.
Cheers.
Paul.
#So you're none the wiser if the cdrom unit is actually working until you go to use it. :huh:
"no spin, nothing" - It might be worth probing TP8 which is tied in with the main data lines to Akiko (CPU/System interface) -> 68000 -> 182-pin MCA edge connector. As from the schematics Akiko seems to be the primarily responsible for the CDROM interface.
As there's no IDE interface and a custom CDrom controller is tied into the aforementioned perhaps there's a conflict/violation from MCA with the presence of your RAM expansion sharing the same bus lines. (*buffered interface needed?)
I've tried to keep this "byte-size" <- pun. This is mainly what I recall from the earlier Amigas, slightly different for the CD32 I imagine with a 68020@14.3MHz.
The FC0-2 is part of the interrupt acknowledge process:
68K generates this function code if it requests an interrupt vector.
Option 1. Provide your own vector (RAM expansion hardware)
Option 2. Don't acknowledge the request and let CPU fetch autovector from the vector base table
Cycle type strobing process (LOW/HIGH 0|1 Bits)
#Function code lines:
FC0-2 (Signal operating state of CPU USER/Supervisor) the output distinguishes program references from data references.
= 68K - Data reference = WRITE
= 68K - Operands = READ (Except PC)
#Bus control lines:
+ AS (Asynchronous) Mode: (As you mentioned using)
1. CPU signals the request: Data bus strobes UDS (upper data)|LDS (lower data)| R/W (read or write byte/word using UDS/LDS) [D15-8 D7-0] AS (Addr$ strobe)
2. CPU then waits till memory informs data ready (DTACK = 0|LOW) DTACK tells CPU data received.DTACK is strobed by external AS memory after a write access to acknowledge that data has been taken over.
DTACK is generated immediately AFTER AS occurs (using remaining cycle).
If slower memory then set XRDY (0|LOW) (similar to DTACK) (sort of an external DTACK) overriding DTACK (1|HIGH) the CPU will then perform "wait states".
Thus AS mode adapts to speed of memory.
(You mentioned not using the following avenue)
+ Synchronous Mode: E (clock), VPA (Valid peripheral addr$ synchronous switch mode [set 0 external decoder]), VMA (CPU answers VPA w/ Valid memory addr$ = 0)
I don't know alot about the DSACK/bus on the 68020, but on the earlier models all except the DTACK, VPA, VMA, RES, HLT, BERR, E signals are buffered; whether this transcends/applicable to your GAL buffered idea.
I've briefly looked at the REV 3 schematic and it could well be you need buffer and use a decoder.
Could explore the DMA further to ensure the Address/Data bus and control signals are being handled/processed/acknowledged correctly by the CPU.
IE: RAM Expansion vs CDROM Bus Master access/privileges.
Well done with your project.
Cheers.
Paul.
you know, I am wondering if this is KICKROM based problem... namely with ADDMEM.
got some stuff to do today, so I doubt I can really get into it, if anyone can I would recommend de-constructing the CD32 KickROM as my spidey sense is telling me this is where at least the other half of the contention is.
the other half is certinaly Akiko based - I am wondering if some Vectors its looking for in chip have been moved to fast...
got some stuff to do today, so I doubt I can really get into it, if anyone can I would recommend de-constructing the CD32 KickROM as my spidey sense is telling me this is where at least the other half of the contention is.
the other half is certinaly Akiko based - I am wondering if some Vectors its looking for in chip have been moved to fast...
skippy
New member
Afternoony Zetro,
I did try that last night. But you do end up with over 6MB of chaos to trace through. Maybe an Action Replay #4 (a1200 version) and/or WinUAE debugger would be easier.
Paul.
Attachments
@bebek
The reason you don't need to worry about /OVR is because there is no Gayle chip in a CD32! Akiko handles most the Gayle functions.
Also, Akiko has a 24 bit address bus and 32 bit data bus so it can access the same memory as the 020.
It's not likely to be a ROM problem since the CD32 was designed for fast memory expansion (i.e. SX-1).
So whats left? Buffering needed on expansion bus or memory expansion board conflict? (i.e. responding to address' used by Akiko registers).
If we could find some way to disable the memory while the board is connected to the expansion port we may be able to answer this question.
See the CD32 memory map here:
http://www.ianstedman.co.uk/Amiga/Page19902/CD32_Info/CD32_MEM_MAP/cd32_mem_map.html
The reason you don't need to worry about /OVR is because there is no Gayle chip in a CD32! Akiko handles most the Gayle functions.
Also, Akiko has a 24 bit address bus and 32 bit data bus so it can access the same memory as the 020.
It's not likely to be a ROM problem since the CD32 was designed for fast memory expansion (i.e. SX-1).
So whats left? Buffering needed on expansion bus or memory expansion board conflict? (i.e. responding to address' used by Akiko registers).
If we could find some way to disable the memory while the board is connected to the expansion port we may be able to answer this question.
See the CD32 memory map here:
http://www.ianstedman.co.uk/Amiga/Page19902/CD32_Info/CD32_MEM_MAP/cd32_mem_map.html
Last edited:
Wow, it is getting more and more complicated 
. I have limited mem to 4Mb but it is still the same. Without simm it boots with red screen and board defective and then cd rom is working. Shame I do not have different mem expansion. I have tried Apollo1240 but it reboots in loop - to be honest I did not connect all lines so it was just for fun.
Anyway, I did it because I have spare memory expansion but now it looks like it is not 3 hour job and I do not have so many hours spare or (most important) the knowledge to carry on with the project so if somebody thinks that is capable of carry on and do something with it I would send the cable I made to him. Please send your CV and cover letter to ...
.
It would be nice to have it back when everything is working.
Thanks to everyone who tried to help me with this.
. I have limited mem to 4Mb but it is still the same. Without simm it boots with red screen and board defective and then cd rom is working. Shame I do not have different mem expansion. I have tried Apollo1240 but it reboots in loop - to be honest I did not connect all lines so it was just for fun.Anyway, I did it because I have spare memory expansion but now it looks like it is not 3 hour job and I do not have so many hours spare or (most important) the knowledge to carry on with the project so if somebody thinks that is capable of carry on and do something with it I would send the cable I made to him. Please send your CV and cover letter to ...
.It would be nice to have it back when everything is working
.Thanks to everyone who tried to help me with this.
@bebek
It's up to you if you want to give up now I guess. You were getting close I think. Everything points toward an address conflict with the memory expansion at this point. Since you have gone this far you might want to check this EAB thread and send a PM to AlexH regarding the signal and LS chip he used on his CD32 memory expansion project.
http://eab.abime.net/showthread.php?t=39114&highlight=CD32+upgrade
It's up to you if you want to give up now I guess. You were getting close I think. Everything points toward an address conflict with the memory expansion at this point. Since you have gone this far you might want to check this EAB thread and send a PM to AlexH regarding the signal and LS chip he used on his CD32 memory expansion project.
http://eab.abime.net/showthread.php?t=39114&highlight=CD32+upgrade
I asked alexh for help and he mentioned: "I wonder if one or other of the signals needed to be inverted... " and I have checked it and there is one 
oh: - R/W. How the hell I could missed this oh:, stupid, stupid stupid :wooha: . When I will have spare minute I will try if it works.
Small update - it does not ... . with inverted R/W the card is not visible at all ... well .from different site it looks like CPUCKLA is inverted too but it is not a job for today, I need to check it with schematics
I can not stop so I checked schematics and it looks like none of them need to be inverted R/W and CPUCKLA are same in A1200 and CD32, every site says something different so I believe in schematics now. Well I will wait for alexh to find his project details.
oh: - R/W. How the hell I could missed this oh:, stupid, stupid stupid :wooha: . When I will have spare minute I will try if it works.Small update - it does not ... . with inverted R/W the card is not visible at all ... well .from different site it looks like CPUCKLA is inverted too but it is not a job for today, I need to check it with schematics
I can not stop so I checked schematics and it looks like none of them need to be inverted R/W and CPUCKLA are same in A1200 and CD32, every site says something different so I believe in schematics now. Well I will wait for alexh to find his project details.
Last edited:
I know nothing about CD32 circuitry, or circuitry in general, but I took a step back and wondered: Is there any chance this could be a power issue? Even if the CD-32 has a custom controller, I would have guessed the drive it would have at least spun up when powered on. Surely the actually drive is a stock part, and would therefore presumably boot up it's internal logic just like any other drive? Is there any chance that the expansion is causing an unexpected drain an not enough power is getting to the drive for it to initialise? Would it be possible to wire power direct to the CD-ROM from another source to test?
