MSX Turbo-R behavior with 1MB external mapper

Page 2/4
1 | | 3 | 4

Par sd_snatcher

Prophet (3498)

Portrait de sd_snatcher

11-07-2010, 01:28

@Jipe

You do have the register fix from this document installed on your MSX, right? Could you please run the

PRINT INP(254)

test on your MSX and post the results here?

Par Retrofan

Paragon (1264)

Portrait de Retrofan

11-07-2010, 09:04

@Jipe

You do have the register fix from this document installed on your MSX, right? Could you please run the

PRINT INP(254)

test on your MSX and post the results here?
hi sd_snatcher, on my Turbo-R GT with 1 MB internal mapper it gives '193' as result. don't know the meaning of this... I only know Sunrise expanded my Turbo-R to 1 MB SIMM a long time ago.

Par Jipe

Paragon (1529)

Portrait de Jipe

11-07-2010, 09:19

on my GT with register fix i have 193 , 11000001 Bin

on my ST with only 512k i have 225 , 11100001 Bin

yes register work Wink

Par Leo

Paragon (1236)

Portrait de Leo

11-07-2010, 11:33

when you expand internal memory and add a register ,this register does not conflict with other mapper since you only have one mapper with fixes.

when you put external mapper ,you have 2 mappers : internal +external . the registers of the internal mapper conflicts with external ONLY when you try reading them. for writing it is ok.

Par opcode

Expert (108)

Portrait de opcode

21-03-2013, 16:24

Leo wrote:

the behaviour is not fixed.

Does anyone knows how to activate the internal r800 mmu + dma 0/1 ?

The reason no one has been able to activate and use the DMA controller, MMU or extra interrupt stuff, is because the register set for those functions hasn't been mapped on the Turbo R. The register set isn't hard mapped as many Z80 compatible implementations out there. Instead, it needs an external decoder. The pin used is pin 10, CSREG, which is active low. In all TRs that pin is connected to VCC, making it impossible to access the register set and thus program the DMA, MMU and interrupt controllers. As implemented in the TR, the R800 is a great CPU deprived of much of its originally planned power and charm. And too bad the CPU isn't available anymore, as it would super cool to have a new board that uses it properly.

Par Gradius2

Hero (626)

Portrait de Gradius2

21-04-2013, 19:24

Anyone did an updated 1MB diagram for GT? The one available wasn't in english and was confuse (not polite).

Par sd_snatcher

Prophet (3498)

Portrait de sd_snatcher

13-02-2016, 19:02

@Jipe

In your circuit to fix the Turbo-R mapper register for 1MB, why have you used a 74LS367 to latch the register read? Since the 74LS670 has tristate outputs, couldn't the pin-8 of the 74LS32 be connected directly to the pin-11 of the 74LS670 and the 74LS367 be eliminated?

Par Jipe

Paragon (1529)

Portrait de Jipe

13-02-2016, 19:10

i'm not the creator of the schematic
i found this circuit in a A1GT buy by a friend in deutchland
just adapt for A1ST and A1GT
have you trying your mod ?

Par sd_snatcher

Prophet (3498)

Portrait de sd_snatcher

13-02-2016, 19:50

We're going to develop a board, but it seems that the circuit needs some optimization and fixes:

1) The 74LS367 seems redundant. Maybe the guy developed the circuit to allow either the 74LS670 or 74LS170 to be used.
2) The Z80 signal /M1 is not being checked on /IORQ activations. This means that interrupt acknowledges may also activate the circuit, leading to risk of conflicts and even the risk to fry the D5 bit.

Par RetroTechie

Paragon (1563)

Portrait de RetroTechie

14-02-2016, 08:33

sd_snatcher wrote:

The 74LS367 seems redundant. Maybe the guy developed the circuit to allow either the 74LS670 or 74LS170 to be used.

If the unused mapper bits aren't driven, then any tri-state output should do to put a value on the data lines. But if circuitry in the Turbo-R actively drives unused bits to some logic level, then you'd need an IC that can deliver more output current to 'overpower' that Turbo-R's circuitry. 74LS367 is such an IC ("buffer"), so maybe it was used for that reason?
Personally I don't know, don't have a Turbo-R, and it's probably documented somewhere. But anyway it's easy to check on real hardware if that is the case or not.

Quote:

2) The Z80 signal /M1 is not being checked on /IORQ activations. This means that interrupt acknowledges may also activate the circuit, leading to risk of conflicts and even the risk to fry the D5 bit.

Nope. For detecting reads/writes to I/O ports, you don't need /M1. Yes if you only want a signal that says "I/O ports xyz are accessed" then you'd need to include /M1 in the decoding circuit. But usually you combine such a signal with /RD or /WR, and in that case you can skip using /M1. That's because in the special case of /M1 and /IORQ going active (interrupt acknowledge but no I/O port access), /RD and /WR both stay high.

So no use of /M1 is a hardware designer unaware of this issue, lazy/dumb, or a smart designer who knows how a Z80 works. Smile2 Either way, I/O port read & write signals that don't include /M1 in the decoding, is known to work - both correct and reliable. As long as /RD or /WR is included in the mix as well.

Page 2/4
1 | | 3 | 4