Good Morning Everybody :D ,
During my "adventures" fixing "The Prayer of the Warrior", i found that the authors discovered a way to use the Z80 interrupt mode 2 without using the correspondant 257 bytes jump table, the problem, this "feature" doesn't work in every CPC.
I'm not going to give now the boring technical details, i have been talking with Executioner and he thinks that it could be useful to get a better understanding if everybody could test the attached files (i have include a DSK and CDTs for easy test) in your CPCs and tell us what colour appears in the border in each test (red, green or anything else) and what CPC model, peripherals you have attached, CRTC type and mainboard version you have (i know that last two things are not easy, but i could make a program that show what CRTC your CPC has).
In my two 6128, with CRTC 2 and 4, the border is always RED, but it's green in one of the test from a person with a CRTC 1 of the spanish forum.
Thanks for your cooperation!!! ;)
Red for all tests on WinAPE 2.0a18 (All CRTC)
Green for all tests on WinAPE 2.0a18 with Plus feature enabled (All CRTC)
OK, I will test it on a real CPC tomorrow... ;D
I'm guessing it's down to the port decoding of the crtc and I register happening to match the decoding?
This then forces a particular value onto the bus?
Now I go and work.
.
QuoteI'm not going to give now the boring technical details
Oh,its not boring.I try the test in my cpcs later i update.
Quote from: TotO on 09:42, 23 September 11OK, I will test it on a real CPC tomorrow... ;D
Thanks TotO :)
Quote from: phi2x on 10:39, 23 September 11I tested it on my real CPC6128 w/ CRTC1.
It shows red border with all the tests.
Thank you very much phi2x :)
Quote from: dragon on 12:03, 23 September 11
Oh,its not boring.I try the test in my cpcs later i update.
Thanks dragon :)
Quote from: arnoldemu on 09:45, 23 September 11
I'm guessing it's down to the port decoding of the crtc and I register happening to match the decoding?
This then forces a particular value onto the bus?
Now I go and work.
Well, Kevin, you know that usually while the data bus is "free", we can find $FF in it ($DF in the CPC+, if i remember well), but that value can change with access to the CPC hardware or the peripherals that you can have attached to the machine.
And by the test that i have made, it looks that is dependent in the motherboard revision, too. How i can not ask to everybody to open his CPC, it's why i ask about the CRTC, a good clue to the motherboard revision... although now that i'm thinking, we could make a project to list the serial numbers of our CPCs, too.
In this test programs, i'm "disturbing" the bus with writtings to the CRTC, to change the value in the bus and in consequence, the mode 2 interrupt jump, it happen that in my CPCs and in the 6128 of phi2x the bus always return to $FF, but in the case of the 6128 of the spanish user that i told before, it never goes back to $FF in the test 1 (that with the HALT in the inifinite loop)... and that it's really interesting :)
The source code is:
ORG $3F40
PUSH BC
LD BC,$7F10
OUT (C),C
LD C,$4C
OUT (C),C
POP BC
EI
RET
ORG $4000
start
DI
IM 2
LD A,$41
LD I,A
EI
; In test 0 this is the infinite loop
JR $
; In test 1 this is the infinite loop
loop
HALT
LD BC,$7F00
OUT (C),C
LD A,R
OR $40
OUT (C),A
JR loop
; In test 2 this is the infinite loop
loop
DI
LD BC,$7F00
OUT (C),C
LD A,R
OR $40
OUT (C),A
EI
JR loop
ORG $4040
PUSH BC
LD BC,$7F10
OUT (C),C
LD C,$52
OUT (C),C
POP BC
EI
RET
ORG $4100
REPT 256
DEFB $40
ENDM
DEFB $3F
END $4000 Sorry, people, i did't want to fill this post of technical info to not to bore you with wibbly wobbly technically wimey stuff before get a few results, because your help is important ;)
In tape what test i Try, news and old?,or only news?
sys can you release the tape images at normal speed cassete?,I have problems in execute it in my old cpc 464(with a problem in the cassette).
Hi dragon! :)
Quote from: dragon on 12:18, 23 September 11
In tape what test i Try, news and old?,or only news?
All, test all, old and new :)
Quote from: dragon on 12:18, 23 September 11sys can you release the tape images at normal speed cassete?,I have problems in execute it in my old cpc 464(with a problem in the cassette).
A sus ordenes caballero, here they are in speed write 0 ;)
PD: Por si te interesa, echale un vistazo a las Amstrad Sinclair Ocio, no recuerdo el número pero había un montaje para ponerle un puerto externo del cassette al 464 a lo 6128 ;)
Ja,no hay problema,va a ir de cabeza al taller de reparaciones de la gamefest,pero no creo que te quieras esperar una semana para ver los test. :) .
cpc 6128 cost down:(sgs z80)
test 0:border red.
test 1:border red.
test 1old:red border.
test 2:red border.
tesst 2old:red border.
cpc464(u,k)gate array 40007 pcb revision 1(mc 0002c). crtc mc6845p cpu z80 sgs.
test 0:red border
test 1:red border
test 1old:red border
test 2:red border
test 2 old:red border
cpc 464 spain:gate arrray 40010 pcb revision pre-preasic(MC0044D). crtc:um6845R cpu zilog z80.
test0:red border
test1:red border
test1old:red border
test2:red border
test2old:red border
Amstrad 6128 plus:revision c motherboard(if i remember o.k).(sgs cpu)
test0:green!
test1:green!(and my tv samsung distorsioned)
test1old:green!
test2:green!
test2old:green!
Thats all.
Muchas gracias caballero :) ... siento no poder escaparme al Gamefest para saludar a todo el mundo.
IMHO it's important to do more tests with as much as possible attached expansions! Real CPCs ;-)
little offtopic:
Taking advantage of I mounted the cost down cpc,I try the test of grimware page:
http://www.grimware.org/doku.php/documentations/devices/gatearray#composite.sync (http://www.grimware.org/doku.php/documentations/devices/gatearray#composite.sync)
(The test vram rasterization timmings.)
I use a mpv001.But in the screen,I view the same effect that 40010 gate array in the left and in the right.
So,If anyone knows how to contact the author of the page,Tell that to incorporate it.
Like I know... the topic here is Interrupt Mode 2 and the values that the CPC delivers. I always thought it's &FF, but SyX already pointed out that it can be also &DF - and maybe anything else???
Actually I remember now that it can be also &FD! Because I had that with some dobbertin expansions. But I'm not completely sure, it was 15 years ago.
Quote from: dragon on 20:21, 23 September 11
So,If anyone knows how to contact the author of the page,Tell that to incorporate it.
You can reach to Grim in grim at cpcscene dot com or the user Grim in this forum ;)
For us non-technical guys, what's the advantage with this?
Quote from: Gryzor on 10:25, 24 September 11For us non-technical guys, what's the advantage with this?
Well, Gryzor, the main advantages are for technical people (this could help to improve emulators or fix games that depends in this feature, ...), but how always it's very important the help from the non technical guys, and for that i can not stop to be grateful for all your help ;)
Quote from: SyX on 12:05, 23 September 11
Well, Kevin, you know that usually while the data bus is "free", we can find $FF in it ($DF in the CPC+, if i remember well), but that value can change with access to the CPC hardware or the peripherals that you can have attached to the machine.
Well I know that the value on the bus for CPC+ is completely predictable. A test program on cpctech shows how you can use interrupt mode 0 on a cpc+ and execute almost any instruction of your choice, this also means the value on the bus for interrupt mode 2 is also predictable.
But for the CPC this is different.
I would be interested to see what difference there is.
I am sure the "costdown"/CRTC type 4 will show a difference, perhaps different gate-array revisions are also different.
Looking at the schematics, I don't think the CRTC has an involvement because it will not be active, neither /RD or /WR are low, so /IORD, /IOWR on normal CPC (not costdown) will not be active. So the difference may be in the Gate-array, or perhaps gate-array latching the bus data at some specific time and keeping it active for longer than required...
I will be interested to see the results to see what is found.
Quotelooking at the schematics, I don't think the CRTC has an involvement because it will not be active, neither /RD or /WR are low, so /IORD, /IOWR on normal CPC (not costdown) will not be active. So the difference may be in the Gate-array, or perhaps gate-array latching the bus data at some specific time and keeping it active for longer than required...
I don't think the gate array is the cause.Mi two 464+6128.Covers 3/4 types of gate array.(and the other is the 40008 only fitted in 664.
Quote from: dragon on 18:02, 25 September 11
I don't think the gate array is the cause.Mi two 464+6128.Covers 3/4 types of gate array.(and the other is the 40008 only fitted in 664.
I made a test. The idea was:
What if the bus value came from video ram. Perhaps /244EN was activated at the wrong time and we saw video bytes on the bus at this time.
So i made a test:
- I set I to &7f, I filled video ram with all possible 256 values, I setup a interrupt table and waited for interrupt.
- 2 interrupts were setup, a "bad" one and a "good" one.
"bad" -> not the expected interrupt
"good" -> one I was looking for, which had a interrupt address based on video ram bytes.
Result: The data doesn't come from video ram in this case.
I can't make the bus make values other than 255.
I have a "new" cpc 464 (Amstrad user repair exchangue :) ),
Later I made a new test with it.
well,I think we need know what are the esact components in the cpcs where the test fail.Each model of chip,that may affected the bus.
Quote from: dragon on 15:42, 14 November 11
I have a "new" cpc 464 (Amstrad user repair exchangue :) ),
Later I made a new test with it.
well,I think we need know what are the esact components in the cpcs where the test fail.Each model of chip,that may affected the bus.
I have another idea which I need to test.
Some instructions do not fill exactly 1 NOP time.
At the end there is time for interrupt to be acknowledged and execution to start.
Time from end of instruction up to the next "NOP" time slot.
Perhaps in this time, there is data on the bus (the instruction itself perhaps)... this is then used.
I need to make a test (using INC IX, INC IY etc).
No problem in my new cpc 464.red border.
Maybe its depend of manufacturer of ram type mounted.
You guys should look what (internal/external!) pheriphery put on the lower 8 bit of the bus, that will lead you to the right direction. Especially external hardware is of interest here.
I couldn't find the original topic, but I tested the "floating" bus.
These results are from Amstrad plus, not tested cpc yet:
When you do an IN of a write-only port, or a port which is not assigned, you will read back the last byte of the opcode used to do the IN. e.g. IN A,(C), returns last byte of that opcode.
In addition, we know that doing an IN to the port 7fxx on Plus, also does a write.
So I present to you some code that only works on a real Plus (hint it shows a raster bar, sorry the colours are like the c64 ;) - blame the "floating bus" ):
org &4000
test:
di
ld hl,&c9fb
ld (&0038),hl
ei
l1:
ld b,&f5
l2:
in a,(c)
rra
jr nc,l2
halt
halt
halt
defs 32
;; set pen
ld bc,&7f00
out (c),c
in d,(c) ;; [4] blue
defs 64-4
in e,(c) ;; [4] magenta
defs 64-4
in a,(c) ;; [4] magenta
defs 64-4
in c,(c) ;; [4] purple
defs 64-4
in c,(c) ;; [4] purple
defs 64-4
in h,(c) ;; [4] grey, same as in b,(c) but without having to re-program B
defs 64-4
in h,(c) ;; [4] grey, same as in b,(c) but without having to re-program B
defs 64-4
in c,(c) ;; [4] purple
defs 64-4
in c,(c) ;; [4] purple
defs 64-4
in a,(c) ;; [4] magenta
defs 64-4
in e,(c) ;; [4] magenta
defs 64-4
in d,(c) ;; [4] blue
defs 64-4
;; black
ld a,&54
out (c),a
jp l1
end test
Also, if I do a read from the asic register page, when it's paged in, but from a memory address which has no register, this too returns the last byte of the read instruction. (e.g. LD A,(&5000) returns the last byte,&3a, &00, &50 which is &50.
Some extra fun on Plus.
EDIT: Test was on a 464 plus with no extra hardware. Not tested on 6128 plus, colours MAY be different, previous tests seemed to indicate it may assert bit 0 to 1. On 464 Plus, it's purples and grey.
Does that prove there's a floating bus? Or are the values just being left in some CPU register than didn't change? A floating bus would give random results, not known results.
Bryce.
Quote from: Bryce on 13:00, 07 December 12
Does that prove there's a floating bus? Or are the values just being left in some CPU register than didn't change? A floating bus would give random results, not known results.
Bryce.
The values seem stable on this 464, so in this case the values are not floating. It does seem to indicate that nothing is asserting the bus and the last read byte is the one that is seen, at least on plus. I am planning another test, where I start to execute from a known register value and let it go into unassigned asic register page, and see what happens, I hope eventually it'll end up executing some garbage as the data drops away.
I'll try the tests (excluding the asic register page one ;) ) on a few other cpcs today and see what happens.
So far it looks to only do it this way on Amstrad Plus.
Tested on:
464 with costdown and 6128 with type 0, both show ff for all values read. Same test.