Some question I have on + range.
Was there some commercially available 464+/6128+ RAM extension ?
Is there any DIY one?
Now, why this question ?
I am currently testing my own RAM/FLASH/CF extension. All seems fine on 6128, but am facing some issue when connected to the 6128+.
Visible symptoms are display corruption and random crash when reading the extension RAM. Writing phase is OK.
After some test, I've probed the DRAM within the plus and found that when probing the RAM RAS signal, the problem vanish.
Also DRAM timing diagram when reading/writing to the extension looks weird as the RAS is going high at the same time the CAS is going low, like the access has been masked, but not completely. I was expecting that CAS did not go low at all.
Is anyone aware of potential RAM timing issue on the + range ?
The only thing I can tell is that all commercial RAM expansions (and that one from Inicron) do work with both the CPC6128 and the 6128Plus. So it shall be doable.
However I do also know that there are some issues with the SYMBiFACE II when running on the Plus. Dr. Zed may know more about it.
Concerning the 464PLUS, the most obvious way is to simply put the missing components ont the motherboard so you have a real 4128PLUS.
On the other hand those computers could have some RAM sticks socket, a bit like the Atari STE... but Amstrad didn't care.
Some issues with RAM extensions and 6128 configs, is that the already existing +64k are often simply replaced by the external +64K... so you may have no gain at all actually.
You should perhaps check up the connections too... are you sure the RAM you put on the extension port is well connected and well powered ?
Also are the RAM chip really compatible ?
I did check the DRAM timing on the CP6128 and found that the RAS/CAS timing where more as expected.
Basically, when accessing the external ram (RAMDIS high), the access to the DRAM is masked.
Masking is done on the CAS cycle of the access, the RAS cycle is still done. However, this masking is only partial and CAS will pulse at the end of the access.
On the 6128, the CAS is going low about 14ns after RAS is going up. That is CAS pulse is not seen by the DRAM as expected with RAS high;
On the 6128+, the CAS is going low about 4ns after RAS is going up. It seems that the DRAM is sometimes taking that for a proper access and memory corruption occur.
As hinted by the fact that problem disappeared when probing the signals, I added 12pf capacitor on both CAS signal.
Now the 6128+ is stable with and without the ram extension.
So, you added the capacitor the the Plus PCB?
It would be interesting to see if this capacitor also solves the problems which has the sf2 with the Plus.
May you like to post a picture ...
How big is your RAM expansion?
Quote from: TFM/FS on 16:14, 10 October 12
So, you added the capacitor the the Plus PCB?
Yes. The capacitors are between NCAS0/NCAS1 and GND, on the DRAM side. I've soldered them directly on the R155/R156, but these can be soldered on the DRAM pad as well. Basically the increased capacitive load creates a small delay.
Quote from: TFM/FS on 16:14, 10 October 12
It would be interesting to see if this capacitor also solves the problems which has the sf2 with the Plus.
I would be interrested too. Does anyone have the sf2 and a plus with problem ?
Quote from: TFM/FS on 16:14, 10 October 12
How big is your RAM expansion?
512KByte "only" :P
Does the ram expansion handle the c3 configuration?
If so how did you implement it?
Quote from: arnoldemu on 17:35, 10 October 12
Does the ram expansion handle the c3 configuration?
If so how did you implement it?
Yes, C3 is part of the specification.
I currently did not test it specifically, but since FutureOS running fine, I guess that it is OK :) .
I will make more exhaustive test later. I am only fully testing mode C4 to C7.
From the extension point of view, C3 is not different from C1. The tricky part is done by the PLD inside the CPC when mapping the upper base 16K to 0x4000.
That is, C3 will not work on 464/664.
Any pictures of this modification ? It may help some of us to fix this issue on Plus ;)
Thanks
Here it is
Cap value is 12pf, 0603 package. The value is arbitrary and is the 1st one I tested.
You may use any other package.
Let us know if this is working for you.
Any pictures of your expansion, and once it's all sorted are you going to release details or maybe build & sell some ?
cheers,
Shane
Quote from: gerald on 17:48, 10 October 12
That is, C3 will not work on 464/664.
Yet dk'tronics managed to make it work Memory Expansion - Code 3 (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/memory-expansion-code-3/)
Do you have any idea how they could have done it?
Picture of the prototype
[attachimg=1]
Quote from: 00WReX on 12:26, 11 October 12
and once it's all sorted are you going to release details or maybe build & sell some ?
Well, as you said, all need to be sorted out.
Current status is :
512K RAM is OK in C4-C7 mode, C3 seem OK, did not test C1/C2.
512K FLASH is OK. However, slot 0 and 7 cannot be used (disabled by default in HW). Flash is programmed using a modified version of TFM ROM manager (Thanks for sharing the code !!! )
CF raw access are OK, however I have some stability issue I need to solve. Hopefully these are related to the prototype nature and long wires.
Read only support for FAT12/16/32 including directory and long name. No AMSDOS integration yet
What I still need to do :
Properly check C1/C2/C3 RAM mode
Ability to remap 1s 64K of the extension to a new location, so 6128 2nd bank is still used and CPC can access the full 640K. I plan to use the additional 64K for file system cache.
Ability to remap FLASH slot 31 to low ROM.
Add I2C RTC, a nice to have for mass storage.
Add write support to FAT filesystem.
integrate FAT support in AMSDOS.
I will then at least release the details of the interface (schematic/code). Building and selling is an other story I will think of later :P
Quote from: IanS on 13:02, 11 October 12
Yet dk'tronics managed to make it work Memory Expansion - Code 3 (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/memory-expansion-code-3/)
Do you have any idea how they could have done it?
No Idea at all ;D . I do not have dk'tronics memory extention to test.
I will try some test later, but for this I need to get my 464 out. The 6128 and 6128+ already take some space.
Quote from: gerald on 14:38, 11 October 12
512K FLASH is OK. However, slot 0 and 7 cannot be used (disabled by default in HW). Flash is programmed using a modified version of TFM ROM manager (Thanks for sharing the code !!! )
Looks good. I did the same in my Flash rom, just mapped out 0 and 7.
How are you enabling write support, there doesn't appear to be any obvious switches. Are you using software write control?
Quote from: gerald on 14:38, 11 October 12512K FLASH is OK. However, slot 0 and 7 cannot be used (disabled by default in HW). [...] Ability to remap FLASH slot 31 to low ROM.
If the ROM 0 can't be used, why not remaping it for the Lower ROM ? (instead of losing the ROM 31)
He's probably enabling the write pin using the address bit of some other ROMs higher up the table: ie: writing to ROM63 is essentially writing to ROM31 etc. I considered this on the MegaFlash, but in the end I chose to use a physical switch to be 100% sure that other hardware wasn't inadvertantly setting the write enable.
@Gerald: Nice hardware, it'll be an impressive little device when it's finished.
Bryce.
Quote from: IanS on 15:59, 11 October 12
How are you enabling write support, there doesn't appear to be any obvious switches. Are you using software write control?
Yes, write is SW controlled by selecting ROM using port DExx instead of DFxx.
There will be switches to individually enable high rom0, rom7, lower rom0 and globally disable all ROM.
Edit : DExx instead of DFxx is inspired by Yarek internal flash
Quote from: gerald on 14:38, 11 October 12
Flash is programmed using a modified version of TFM ROM manager (Thanks for sharing the code !!! )
My pleasure. :) Let me know if I can help in any way with ROManager :)
Quote from: Bryce on 16:07, 11 October 12
I considered this on the MegaFlash, but in the end I chose to use a physical switch to be 100% sure that other hardware wasn't inadvertantly setting the write enable.
I've considered a write switch as well, but :
- I've tried to minimise the number of switches and reseve them for functional option (like specific rom enable)
- the flash used is programmed using the standard JEDEC algorithm (simple FSM, but unlikely to do unlock it by accident). so even if the SW unlock the write, the CPC may crash by read the ROM, but the flash should not be corrupted. The flash used on the MegaFlash uses a really simple algorithm, but is easy to corrupt by accident if not write protected.
Quote from: Bryce on 16:07, 11 October 12
@Gerald: Nice hardware, it'll be an impressive little device when it's finished.
Thanks ;)
Quote from: TotO on 16:05, 11 October 12
If the ROM 0 can't be used, why not remaping it for the Lower ROM ? (instead of losing the ROM 31)
ROM and ROM7 will be usable later. Current PLD just disable them.
The Idea is to be able to have :
Internal Low ROM replaced external high ROM31. When in this configuration, higher ROM31 is no more visible
Internal High ROM0 replaced external high ROM0
Internal High ROM7 replaced external high ROM7
All at the same time, so TFM will be able to give us a FutureBasic :D .
Quote from: gerald on 16:59, 11 October 12
The flash used on the MegaFlash ... is easy to corrupt by accident if not write protected.
Therefore I do recommend to enable the SDP after installing all ROMs. With SDP active it's nearly impossible that the Flash gets corrupted.
The last update of ROManager supports to enable / disable the SDP, this feature was missing in the first release of the application though.
I would be even better if the Rom manager does the lock/unlock sequence automatically when programming/erasing a rom slot.
Quote from: gerald on 17:09, 11 October 12
I would be even better if the Rom manager does the lock/unlock sequence automatically when programming/erasing a rom slot.
Well, I actually thought about that... but in that case it would make the Flash in-accessible for other software like QCMD. And in France they do a remake of the MF, using a ROM which provides a simple !BURN command for people who like it easy (which don't know about SDP either).
Well, but back to topic! I'm really curious what your card will be able to do at the end. I like the idea of the mass-storage option. If it would have a mouse port and an RTC then it would be the new SF2 ;D
Quote from: TFM/FS on 17:13, 11 October 12
Well, I actually thought about that... but in that case it would make the Flash in-accessible for other software like QCMD. And in France they do a remake of the MF, using a ROM which provides a simple !BURN command for people who like it easy (which don't know about SDP either).
Nothing killing, just add the lock/unclok to the ROM and QCMD ::) . It would be safer for everyone and save some time when using a brand new flash.
Quote from: TFM/FS on 17:13, 11 October 12
Well, but back to topic! I'm really curious what your card will be able to do at the end. I like the idea of the mass-storage option. If it would have a mouse port and an RTC then it would be the new SF2 ;D
RTC is planned :laugh:
But no mouse, as Bryce adapter solution seem more compatible than the SF2 one.
Quote from: gerald on 17:25, 11 October 12
But no mouse, as Bryce adapter solution seem more compatible than the SF2 one.
Sure, PS2 is really outdated today :laugh: :)
Quote from: TFM/FS on 17:27, 11 October 12PS2 is really outdated today :laugh: :)
But perfectly does it's job... Like a CPC...
Sure, but where to buy a PS2 mouse? (No, no link to ebay for USED ones please :laugh: ).
The point is: If you do in new, then really do it well 8) ;) However, to have a mouse which provides delta-X and -Y values instead of up, down, left, right is surely appreciable.
Quote from: TFM/FS on 19:44, 11 October 12
Sure, but where to buy a PS2 mouse? (No, no link to ebay for USED ones please :laugh: )
On Amazon for exemple...
A great NEW Logitech S96 optical PS/2 mouse (3 buttons / wheel), for 6€. :laugh:
The MegaFlash uses a very simple Flash and manual write control, but my goal was a "Low-cost" ROMBoard that lots of people would use, so certain decisions were influenced by this, but I think it reached its goal and a lot of people are very happy with it.
Regarding the mouse, AMX standard was the only mouse standard that was really supported with software back in the 80's, so even if a new PS/2 mouse solution is possible, like on the SFII, it isn't as useful as a 100% AMX solution, because the software to support old software isn't there. That's why I stuck to 100% AMX, even if it's not the best solution using todays technology.
Bryce.
Quote from: gerald on 14:38, 11 October 12Ability to remap 1s 64K of the extension to a new location, so 6128 2nd bank is still used and CPC can access the full 640K. I plan to use the additional 64K for file system cache.
That mean the 6128 only get the FS cache ?
To get all CPC definitively "compatible", I though that it will be better to lose this embedded 64K and using 64K from the expansion as FS cache for 464/664 too.
So, you finally get 512K RAM and 64K for the FS:
- Main : 64K
- Extended : 448K
- Buffer : 64K
No? :)
I remember the Inicron 512 KB RAM expansion. It had some excellent features, which makes me using it still.
- It's using battery buffered S-RAM and so you have a real RAM disc, which hold data for a year or even longer. So my CPC can be used as real disc-less station.
- Now, they added a switch which allows to switch between the 64 KB from the external 512 KB and the 64 KB from the 6128. And this feature *IS* quite usefull for a variety of applications :D
Quote from: TotO on 14:43, 14 October 12
That mean the 6128 only get the FS cache ?
To get all CPC definitively "compatible", I though that it will be better to lose this embedded 64K and using 64K from the expansion as FS cache for 464/664 too.
So, you finally get 512K RAM and 64K for the FS:
- Main : 64K
- Extended : 448K
- Buffer : 64K
No? :)
Yes :)
The idea was to have the 64K cache whatever the CPC is.
But there is a small issue :
if the CPC has only 64K base (464/664), the extension has to cover bank 0 to 30, bank 31 become the cache
if the CPC has 64k base and 64k extension (6128), the extension has to cover bank 1 to 31, bank 0 become the cache
This can be done either by a configuration switch or a SW switch. What is the best solution ?
I would use a SW solution, which is activated by the FS ROM after HW detection.
About the cache :
The current implementation of FAT FS does not use any cache except for one sector for FAT structure manipulation and one general purpose sector (mainly for directory entry parsing). The not yet implemented DIR command will also requires a quite big buffer.
Also, support for long name and directory requires buffer to store those long name (256bytes).
My target is to have a transparent AMSDOS integration so SW can be used as is (if they used AMSDOS for file IO). However, buffers reserved by AMSDOS are too small for FAT. Here comes the 64K as a FS reserved memory for all these buffers.
For SW not using amsdos, i plan to have ROMed support lib for emulating sector/track access. But these SW will need to be patched in order to use these function.
Unused space in this buffer can then be used as cache, but it may be counterproductive :
- when doing a uncached read, data is put at target place
- when doing a cached read, initial access will be put in cache and then copied to target place. Reread will only copy from cache. This will surely slow down read, as the only real gain is the media access time, not the throughput.
Hi gerald,
Great piece of hardware you've got there :o
I wish I had enough electro skills to do the same.
Quote from: gerald on 18:58, 14 October 12
The idea was to have the 64K cache whatever the CPC is. But there is a small issue
I though that is better to lost the 6128's extended 64K to get the same computer when upgraded, else some programs will again not work on 464/664.
About the disk cache, using the same bank for all. (0 for exemple)
At end, everyone will get 512K.
Quote from: TotO on 14:14, 16 October 12
I though that is better to lost the 6128's extended 64K to get the same computer when upgraded, else some programs will again not work on 464/664.
That's a good ideology, but sadly it will never work. Because the 464/664 will never be able to use RAM configuration &C3. This one needs a PAL in the 6128, and this PAL is missing in the 464/664.
So we can use all 640 KB with good conscience.
Quote from: TFM/FS on 15:31, 16 October 12
Because the 464/664 will never be able to use RAM configuration &C3.
The dktronics expansion supports &c3 (no idea how, see this thread Memory Expansion - Code 3 (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/memory-expansion-code-3/) )
In this case, how a 464/664 can manage the existing external RAM expansion ?
Let the 6128 do the same ???
Quote from: IanS on 17:07, 16 October 12
The dktronics expansion supports &c3 (no idea how, see this thread Memory Expansion - Code 3 (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/memory-expansion-code-3/) )
That's an urban legend! It can not alter the internal memory management of the CPC motherboard. Not even Dobbertin could do that.
Quote from: TotO on 17:45, 16 October 12
In this case, how a 464/664 can manage the existing external RAM expansion ?
Let the 6128 do the same ???
The point is that RAM configuration &C3 relocates block 3 from &C000-&FFFF to area &4000-&7FFF. And the logic needed for that must be on the motherboard. Since an external card can NOT alter the PCB's RAM configuration.
Quote from: TFM/FS on 18:05, 16 October 12
That's an urban legend! It can not alter the internal memory management of the CPC motherboard. Not even Dobbertin could do that.
I have a 64k dk'tronics ram expansion for my 464.
I tested it and c3 works with it.
It is truth. :)
Quote from: arnoldemu on 18:07, 16 October 12
I have a 64k dk'tronics ram expansion for my 464.
I tested it and c3 works with it.
It is truth. :)
Does it bank the Video-RAM to &4000? How did you verify that &C3 works?
Quote from: TFM/FS on 18:09, 16 October 12
Does it bank the Video-RAM to &4000? How did you verify that &C3 works?
Yes it does.
It works the same as the cpc6128 with 1 difference.
If you enable the upper rom, on 464 it will move when you use configuration c3. On 6128 it doesn't.
So it seems A15/A14 is exchanged.
I have sent a PM to IanS. He is welcome to borrow my 64k ram expansion and find out how it works :)
How did I test?
I made a test program that writes a byte into each 16k page.
0,1,2,3 for main ram.
4,5,6,7 for c4,c5,c6,c7.
Then I changed each configuration, c0,c1,c2,c3,c4,c5,c6,c7 and I read the values the z80 can see.
I checked result on 464 + 64k dk'tronics ram, 6128 and I tried 6128 with 64k dk'tronics ram (I wanted to see does dk'tronics take priority over internal ram).
I have attached the test code (it needs other files to make a binary, but you can read it here).
in the code
"has_ram" does a test as if no extra ram was connected.
"external_ram" does the test to check for 64k dk'tronics ram on 464.
Quote from: arnoldemu on 18:10, 16 October 12
Yes it does.
It works the same as the cpc6128 with 1 difference.
If you enable the upper rom, on 464 it will move when you use configuration c3. On 6128 it doesn't.
No, sorry. If a 6128 would work like you say, then FutureOS would not be able to display it's mouse-arrow sprite on a 6128. But it does! Because it uses RAM config &C3 and the ROM is switched on!
No offense dear friend. But I can't agree with you here.
Quote from: TFM/FS on 18:15, 16 October 12
No, sorry. If a 6128 would work like you say, then FutureOS would not be able to display it's mouse-arrow sprite on a 6128. But it does! Because it uses RAM config &C3 and the ROM is switched on!
No offense dear friend. But I can't agree with you here.
It is ok for us to disagree.
Perhaps you will believe me when somebody else prooves me to be correct?
Quote from: arnoldemu on 18:10, 16 October 12
I have sent a PM to IanS. He is welcome to borrow my 64k ram expansion and find out how it works :)
I also have a 64K expansion (upgraded to 256K), I've not tested it in &c3 mode.
I've traced a few PCB's, it's dull and tedious, so unless someone else has traced the dktronics PCB, it will have to remain a mystery as far as I'm concerned, for now. (I may get curious, but not in the near future)
Quote from: arnoldemu on 18:18, 16 October 12
Perhaps you will believe me when somebody else prooves me to be correct?
Can you publish the code that you used to test the &c3 mode.
Quote from: arnoldemu on 18:10, 16 October 12
If you enable the upper rom, on 464 it will move when you use configuration c3. On 6128 it doesn't.
So it seems A15/A14 is exchanged.
A15/A14 are cannot exchanged on 464, but the move is physically possible because of way the ROM is connected to the bus.
Only A[14:0] are connected to the ROM. The gate array then enable the ROM according to the rom configuration register and A15 state.
Seeing the upper ROM at 0x4000-0x7FFF mean that the gate array enable the ROM when A15 is low and upper rom is enabled.
The gate array are different on 464 (40007/40008/40010) and 6128 (40010). They behaviour can be different.
@arnoldemu : did you test it on a 40007 / 40008 / 40010 or even on cost reduced version ?
I've just opened my dktronics memory expansion.
There is a transistor (BF240) that pulls A15 to +5v. I think that explains it, when the CPU is trying to read &4000-&7FFF, the memory expansion pulls A15 high, which means the reads will actually be from &C000-&FFFF.
Seem like quite a hack, but I guess it works.
Quote from: arnoldemu on 18:18, 16 October 12
It is ok for us to disagree.
Perhaps you will believe me when somebody else prooves me to be correct?
There would be an easy way to do that (And I already apologise for coming to that ...).
If you run FutureOS on a 464 then the mouse pointer leaves a smear, because RAM config &C3 does not work.
In case your dk'tronics RAM expansion can make &C3 working, then there would be no smear (it would run like on an 6128).
If you could check that, we would know if &C3 can be really enabled on 464/664 by using such a kind of RAM expansion.
I also have a 464 and several DKTronics RAM expansions. I can try a few things too when I get time. A question to the other hardware guys here: RAMDIS seems to be connected on the 464 to something although it should technically have no function on a 464, at least not the function found on a 6128. There's a track on the PCB, but it's not mentioned on the schematics (as far as I can see). I think I remember testing it at one time and discovering that it was attached to an address line, but I don't remember which one. So the hardware "trickery" might be on both sides. Have any of you looked at this?
Bryce.
Quote from: IanS on 19:42, 16 October 12
I've just opened my dktronics memory expansion.
There is a transistor (BF240) that pulls A15 to +5v. I think that explains it, when the CPU is trying to read &4000-&7FFF, the memory expansion pulls A15 high, which means the reads will actually be from &C000-&FFFF.
Seem like quite a hack, but I guess it works.
:o :o :o
How can the expansion know that the access is in 0x4000-0x7FFF range if A15 is pulled high ? Well, just guessing, address setup time can be used for that, and A15 is forced only during the actual rd/wr access (RDn/WRn low) ?
This would explain the ROM beeing visible as well : gate array see A15 high.
But this create a short circuit on A15 pad of the Z80. :'(
Quote from: Bryce on 20:06, 16 October 12
I also have a 464 and several DKTronics RAM expansions. I can try a few things too when I get time. A question to the other hardware guys here: RAMDIS seems to be connected on the 464 to something although it should technically have no function on a 464, at least not the function found on a 6128. There's a track on the PCB, but it's not mentioned on the schematics (as far as I can see). I think I remember testing it at one time and discovering that it was attached to an address line, but I don't remember which one. So the hardware "trickery" might be on both sides. Have any of you looked at this?
Bryce.
Too much beer already ;) : look on the middle left side of the ASIC in the 464 schematics.
RAMDIS does the same as on the 6128. It disable the 74LS373 buffer that latch the data from the DRAM. RAMDIS is ORed (IC112) with the RAMRDn signal from gate array. The latch also isolate Z80 bus from data read by the gate array.
My CPC doesn't have an ASIC, I'm talking about a classic 464 here.
Bryce.
Haven't started on the beer yet, but you've just given me a great idea :)
Quote from: Bryce on 20:21, 16 October 12
My CPC doesn't have an ASIC, I'm talking about a classic 464 here.
Bryce.
Haven't started on the beer yet, but you've just given me a great idea :)
Ok, you got me. My brain was thinking gate array, and my finger seems to have they own brain.
Too much beer already? :D
Edit: Maybe my memory is going. I was try to figure out how C3 worked on a 464 (about 10 years ago) and I'm sure I found some very strange undocumented connection to the expansion bus on the 464. I thought it was the RAMDIS signal, but maybe it wasn't. I'll have to see if I took any notes on it.
Bryce.
QuoteToo much beer already?
For once it's not me... ;D :P
That don't explain why a 256K DK'Tronics RAM expansion work as well on 464 as 6128 (disabling the 64K).
It will be interesting to know how to do the same with the 512K RAM expansion.
I though that C3 work on all CPC...
And Pac-Man use all the modes except $C2, if a ram expansion doesn't support those modes you get a nice guru meditation ;)
Sorry if this is totally irrelevant but I noticed this the other day when I ran the SyX ramtest program.
On a normal 6128 you see this...
[attachimg=1]
On a 664 with DK'Tronics 64K expansion you see this...
[attachimg=2]
Not sure how the program works, but anyway that's what it reports.
Cheers,
Shane
After pondering a while last night as to whether I really am going mad, I got out my notes from back then. I can't find anything regarding what I mentioned earlier, the expansion ports on the 464 and 6128 were deemed to be identical. The only differences I've noted (other than the presence of the PAL and the "D7 AND D6" Signal) were that A4 of the RAM ICs has a pull-up resistor connecting it to /CASADDR (680R) and A5 of the RAMs has a pull-up resistor (680R) directly connected to the 5V rail. Neither of these are present on the 464. They also wouldn't be of any help in achieving &C3 though. So after enjoying the beer that gerald kindly suggested I consume, I sat back and began to accept that fact that I probably am going mad, but it doesn't seem as bad as I thought it would be :D And I've still no idea how I'd achieve &C3 on a 464.
Bryce.
Quote from: gerald on 18:34, 16 October 12
A15/A14 are cannot exchanged on 464, but the move is physically possible because of way the ROM is connected to the bus.
Only A[14:0] are connected to the ROM. The gate array then enable the ROM according to the rom configuration register and A15 state.
Seeing the upper ROM at 0x4000-0x7FFF mean that the gate array enable the ROM when A15 is low and upper rom is enabled.
The gate array are different on 464 (40007/40008/40010) and 6128 (40010). They behaviour can be different.
@arnoldemu : did you test it on a 40007 / 40008 / 40010 or even on cost reduced version ?
I tested it on a costdown 464. I think I also tested it on a classic 464.
I couldn't test it on a 664 or 6128 because of the position of the cables relative to the expansion port.
I needed an extension to do that, but mine doesn't work currently :(
Quote from: IanS on 18:19, 16 October 12
Can you publish the code that you used to test the &c3 mode.
I will later.
Quote from: arnoldemu on 09:40, 17 October 12
I will later.
Attached is a zipped file containing a dsk with "ramcheck" on it.
Run it.
It will say "succeeded" or "failed.. got .. expected ..".
The test waits for a keypress when the screen is full of text. it will then say if all the tests are done, and the final press of the key will reset back to basic.
On 6128 it will all pass. It has been setup this way.
On 464 (at least my 464 with it's dk'tronics ram) it will fail when using c3 config and upper ROM *ENABLED*, but the C3 config without ROM will PASS.
The "expected" numbers. 01,02,03,04 for main ram &0000-&3fff, &4000-&7ffff, &8000-&bfff, &c000-&ffff.
5,6,7,8 for 64k ram pages normally accessed at &4000-&7fff using c4,c5,c6,c7.
All combinations are checked, c0,c1,c2,c3,c4,c5,c6,c7.
Extra ram above 64k is not checked, this test is only to check that c0,c1,c2,c3,c4,c5,c6,c7 are successful.
If needed I can write a test to check that the other combinations work as expected with 256k and 512k ram expansions.
The test will fail with C3 and ROM enabled on 464. ROM is read from &4000-&7ffff. Extra ram is read at &C000-&ffff.
Look for the "got" byte, and look it up in the rom at offset &1000.
Tests on other systems (664, other dk'tronics ram expansions and other compatible expansions will be interesting to see).
thanks.
Quote from: 00WReX on 23:22, 16 October 12
Sorry if this is totally irrelevant but I noticed this the other day when I ran the SyX ramtest program.
On a normal 6128 you see this...
.
.
.
On a 664 with DK'Tronics 64K expansion you see this...
.
.
.
Not sure how the program works, but anyway that's what it reports.
Cheers,
Shane
Really strange result 00WReX, jajaja. It looks that i have a one or two gremlins in the code :P , i will check the next time that i go to see the Madrid people, because i don't have any 64 kbs computer, neither ram expansions to check, and my 6128s and winape always give the correct result.
Can somebody give OS-Infos a try? That shall work. If not, then we see a strange behaviour of the hardware.