I'm having a play at creating a replacement gate array using the new Raspberry Pi RP2040/Pico microcontroller. The first attachment shows the development board with the original 40007 and a pair of Picos. On the left are a bunch of jumpers for the output signals so I can select them between those from the original GA and the Picos. Jumper on right = GA, jumper on left = Pico.
As you can see all the basic timing signals are working, and I'm currently exploring the video output. I have video output running for all three video modes. The other attached photo shows the Mode 0 output. A few notes on this:
I'm currently passing the 3V outputs from the Picos straight to the Amstrad. I think this is why the blue channel is broken. Red and green are actually looking surprisingly good. And the current colours are either on or off with no HiZ mode, so only two colours per channel. And some of those lines are black to my eyes but the camera shows them with colour. My next board revision will buffer the outputs and also upgrade to 8-bit colour.
/SYNC should be trivially easy to generate but getting it to sync with the colour output will take more work.
I have some code for /RAMRD and /ROMEN on paper but it needs pins to be rearranged before I can test it.
/INTERRUPT is the one I'm not looking forward to.
The current code doesn't read any settings data (output from the z80). My next board revision will make this much easier.
PS. I'm currently using the Pico boards but it should be possible to shrink things to a just use the raw RP2040 chips and, hopefully, fit the whole think within a DIP-40 size package.
My original plan was to use a single RP2040 once I'd worked out how to multiplex the signals in some way to fit into the available pins. However, the lure of 8-bit colour is a tempting reason to keep it using twin chips. They're pretty cheap anyway so it's not really a cost problem. And there is already code available to generate a HDMI signal using a Pico. I'm not sure there's enough processor cycles to do everything though.
(Sorry, attachments aren't showing on the preview. Let's see if they're on the final post...)
Quite nice first results. Keep the work going. The Garry is what we need. :) :) :)
Great stuff!
This looks promising :o 8)
Good work, very interesting use of a microcontroller.
What would the purpose of 8-bit colour on the basic CPC? I presume that means RGB332?
Will you use an I2C DAC for this video output, as the Pico SoC doesn't have DACs, but lots of I2C?
Just an idea: Would that make it possible to use the "abandoned" 5 colours? I love the CPC palette but I miss dark grey and brown tones. Colour 28-32 could give us e.g. 2 more shades of grey and 3 shades of brown/skin tone. Gone would be the need to paint faces in orange or dark scenes in blue and purple.
As colours 28-32 can already be accessed by software (even BASIC), I would expect this could easily be implemented. New software would not need to implement something that is not working on a normal CPC. It could select a slightly different palette if the new gate array is recognized or stick to the original palette for all unmodified CPCs.
Quote from: eto on 10:35, 30 April 21
Just an idea: Would that make it possible to use the "abandoned" 5 colours? I love the CPC palette but I miss dark grey and brown tones. Colour 28-32 could give us e.g. 2 more shades of grey and 3 shades of brown/skin tone. Gone would be the need to paint faces in orange or dark scenes in blue and purple.
As colours 28-32 can already be accessed by software (even BASIC), I would expect this could easily be implemented. New software would not need to implement something that is not working on a normal CPC. It could select a slightly different palette if the new gate array is recognized or stick to the original palette for all unmodified CPCs.
this will make incompatibilities with old softwares
there is NO free color, there are duplicated colors so assembly programms may use one or the mirrored color
also forget the idea of 0-26 color index, that's not hardware indexes, see http://www.cpcwiki.eu/index.php/Gate_Array#Palette_sorted_by_Hardware_Colour_Numbers
Not really a good idea to add arbitrary colours on the existing palette.
The best will be to support the Amstrad Plus features for all CPC, but the address lines will miss do to it.
Nothing wrong with having alternative behaviour, since you can gate it behind an option. Nobody's suggesting it be permanently enabled.
I wonder if you were to use a pi zero running RGBtoHDMI as the second board. Perhaps then you could then make use of the hdmi out?
Curious to know what level shifters you would use? Won't you need a lot of them?
Quote from: pelrun on 11:14, 30 April 21
Nothing wrong with having alternative behaviour, since you can gate it behind an option. Nobody's suggesting it be permanently enabled.
The magic option.
Quote from: TotO on 12:51, 30 April 21
The magic option.
something like Asic unlock sequence? ;D
which open access to 4096 colors? :P
Quote from: roudoudou on 13:06, 30 April 21
something like Asic unlock sequence? ;D
which open access to 4096 colors? :P
Sure, with the growing interest for the Amstrad Plus those last years, that will be the best. ;)
Sorry, what is this 'Amstrad Plus'? Sounds like a healthcare program of some sort..?
First get it working reliably. Then add a register to change the version of CRTC it emulates!
Then add extended palette, and hardware scrolling (Plus compatible registers, if possible), and as the Pico has lots of onboard RAM, a Sprite engine, but it might be missing some timing signals...
But few people would own it, so is it worth it? At some point you might as well just create a CPC++ dream FPGA system!
Quote from: Sykobee (Briggsy) on 14:57, 30 April 21But few people would own it, so is it worth it?
If it's compatible, I guess it's worth it. CPC repairs would be one aspect, as the gate array is a chip that is hard to source. But also the "upgrade" path to more PLUS features for a normal CPC would be an awesome achievement and maybe even a reason to upgrade with a working gate array.
Quote from: rexbeng on 14:25, 30 April 21
Sorry, what is this 'Amstrad Plus'? Sounds like a healthcare program of some sort..?
It is the name of the Amstrad range of computers succeeding the Amstrad CPC.
Quote from: TotO on 16:33, 30 April 21
It is the name of the Amstrad range of computers succeeding the Amstrad CPC.
So it is a healthcare program!
Sorry, it is true! ;D
Quote from: rexbeng on 16:42, 30 April 21
So it is a healthcare program!
CPC is a healthcare programm, see the website www.cpc.com
To try and answer some of the comments:
The next board revision uses a 74LS/HCT245 and resistor DAC for the video out. It's using RGB332. The issue might be the blue channel, I'll need to use three of the available values for the standard 0%, 50%, 100% which means the fourth available value will be screwy in-between value. I'm not too sure what's available in DAC ICs. The available bandwidth of the Pico means that there would need to be a separate channel for each colour.
I would envisage emulating the standard palette out of the box with some kind of hidden command sequence to enable additional features. The 8-bit colour depth would enable custom palettes. It would also be possible to create additional video modes. At least within the limitations of the rest of the hardware.
Creating all the features of the Plus models wouldn't be possible due to the signals available to the gate array. However, a subset or modified feature set would be possible. I could envisage the ability to have some form of sprites. The challenge here may be getting the data in.
A Pi Zero would be an alternative way of doing this. The Pico should give a more compact and lower cost solution though.
Regarding level shifters: the original GA has 19 input lines and 16 output lines. I'm generating the 16MHz XTAL signal on board so don't need that line. For the other 18 I'm using (will be using) a pair of 74LVC244 For the couple of left over signals I can use a resistor divider or diode plus pull-up. For output a 74LS/HCT244 will buffer the video lines to 5V. For the rest of the signals the 3.3V output is compatible with 74LS logic already but something such as a diode and pull-up will be needed for the open-collector lines to protect the Pico from signals from external devices.
I'm not emulating the CRTC since that's a separate chip on the standard CPCs. I don't see any reason that a Pico couldn't emulate a 6845 though. After all it's mostly just counters. If you did that you could then play with custom modes, or switch versions etc. (Not that that's on my to-do list at the moment though).
The use case for this is really the fact that GAs are so are outside of a CPC and there needs to be some way to replace them as they fail. Also, I'd love to create a newer revision of the CPC hardware but pulling chips out of existing machines isn't really a viable option.
And if you have a replacement GA then you can also play around with the signal timing. Which means you might be able to slip in a faster z80 ;D [size=78%](although you'd have to replace to 4164s at the same time).[/size]
About colors... the KC compact (CPC clone) got 32 of them. Then be compatible to it. :)
And you know what? Have this as option (set a bit somewhere), so everybody is fine.
But let's build the basement first and after that the penthouse. It just would be AWESOME to have a 40010 replacement.
Progress Update
I now have the revision 2 development board. Picos are generating everything except /ROMEN, /RAMRD, /SYNC and /INT.
Resistor DAC is temporary - allows me to play with other stuff. I'll be revising later to improve colour accuracy (which will also need to involve acquiring actual Amstrad monitors for testing).
Screenshots below show Picos versus Amstrad output for each display mode. Pico versions all show display glitches - pixels stretched or missing. This is due to the code occasionally missing input pixels or not sending output pixels in time. The current code is simply 'read pixels, process, output pixels'. I'll be updating the code to use DMA and buffer both input and output data which will fix these issues. It will also meaning generating SYNC from scratch, so I'll leave it for now and come back later. (And note that the /SYNC signal is still coming from the Amstrad gate array so the image is not totally aligned correctly).
The code is now generating border pixels so it's processing the VSYNC, HSYNC and DISPLAY_EN signals from the 6845.
My next step will be to read settings data from the CPU so I can change modes, palettes colours etc.
The screenshots show the Pico gate array versus the Amstrad equivalent for each mode. Pico versions have duller colours and display glitches :)
Amazing stuff!
This is really impressive :o 8)
Quote from: Bread80 on 17:12, 10 July 21I now have the revision 2 development board.
Would you be willing to share your design? I am curious how easy or hard it is to use a Pico with the CPC...
Schematics and software will certainly be open sourced. I'm haven't decided whether to open source the gerbers (when it gets reduced to a DIP-40ish size). In any case the PCBs won't be easy to hand assemble with the tiny components used.
I'm not sure what you mean about how easy the Pico is to use with the CPC. It needs level conversion for any signals into the Pico. The CPC uses 74LS chips so signal from Pico to CPC are okay as is. In software terms then it depends what you want to do with it. It's plenty fast enough to deal with a 4MHz Z80. (Things get tight with the 16MHz gate array though).
What's the current status Bread80 ?
@genesis8 , sorry for the slow reply.
I now have a smaller version which fits neatly into the DIP socket. It's using a pair of RP2040Stamp which is about as close as you can get to an raw RP2040 whilst still being able to hand solder.
There's still one or two issues with the board, and I need to finish updating the code be fully compatible with it.
I'll probably do another revision in this format before I try to miniaturise it.
2023-02-24 21.59.14Small.jpg
Thanks to keep us updated about your great advances.
A slow one is better than none :-)
Thanks.
Quote from: Bread80 on 11:37, 13 May 23I'll probably do another revision in this format before I try to miniaturise it.
You are not so far from that: https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/a-minimal-gate-array/msg198585/#msg198585
Quote from: genesis8 on 20:55, 14 May 23A slow one is better than none :-)
Thanks.
Sometimes thing look to be slow. But few know how much hard work is behind it. :)
Mine is a completely different design. No FPGA. All done with ARM processors. Probably a bit more technically complex, but far easier to reprogram and add extra features :)
Although mostly because I've got far to many projects on the go to devote enough time to any single one of them.
Those small ARM microcontrollers are really neat - fast enough to do in software what used to take hardware. Do you make use of the Pico's fancy I/O controllers to help with some of the video signal generation?
Quote from: Bread80 on 18:37, 16 May 23Mine is a completely different design. No FPGA. All done with ARM processors. Probably a bit more technically complex, but far easier to reprogram and add extra features :)
I know that. I mean about the integration, not the way to do it. :)
Quote from: Sykobee (Briggsy) on 17:25, 17 May 23Those small ARM microcontrollers are really neat - fast enough to do in software what used to take hardware. Do you make use of the Pico's fancy I/O controllers to help with some of the video signal generation?
Yes, lots of PIOs.
The system signals are almost exclusively PIOs and PWMs - the only thing there using CPU core is when the RAM/ROM enable changes. (The code writes the new settings to a PIO).
The video uses CPU core for the pixel decoding and I/O. There's also a bunch of PIOs and DMAs involved. I'd like to rewrite the video to use exclusively PIOs and DMAs, but doing it that way is exceptionally complex.
Since you use PWMs ... could it theoretically be possible to add more colors?
Quote from: GUNHED on 13:34, 18 May 23Since you use PWMs ... could it theoretically be possible to add more colors?
Video out is unrelated to the PWMs - they're just driving clock (etc) signals.
The video out is 8-bit RRRGGGBB, so 256 colour. There's a look up table in the code to convert decoded bytes to the CPC palette. So, yes, you could change the 'hardware' palette, or use additional colours.
One of my plans is to add an 'enhanced mode' for writing data to the gate array. That would allow you to access additional features beyond the standard 'command set'. The fun part will be making that compatible with the original firmware ROMs :)
That's great!!! I'm really looking forward to enhanced modes an will of course support them with my OS. Also for the Firmware it should be doable. The guys who created Firmware 3.x will surely be happy to add such features. If not a patch can be done hopefully in quick time. :) :) :)
@Bread80 any update on this?
Quote from: SerErris on 21:44, 05 September 23@Bread80 any update on this?
Not much progress recently. I'm getting too carried away on other projects, including a couple of CPC related ones :)
With the release of the Raspberry Pi RP2350 (as used in the new Pico 2 board) I'm picking up this project again. The new chip has five volt (ie. TTL level) tolerant pins, 48 GPIOs, and enough PIOs and DMAs that it should now be possible to emulate the gate array on a single RP2350 with minimal additional hardware.
In the first article I give an analysis of the various pins on the gate array and group them into functional blocks ready for the implementation.
https://bread80.com/2024/08/11/pico-garry-2350-part-1-signals/
In the second article I do a deep dive into the implementation of the FSIGS block (signals with fixed timings) using a PIO, a DMA, and an array of signal levels in memory.
https://bread80.com/2024/08/25/pico-garry-2350-part-2-fsigs-fixed-signals/
I think this chip has huge potential for emulating hard to find vintage hardware. I hope my writings are useful to anyone who wants to know more about how it can be used in interesting ways.
Maybe you are the first one within reach to make an 8MHz CPU version.
One read screen, one read/write memory per one 4 clocks cycle
You could also add an option for a custom palette.
Quote from: McArti0 on 06:39, 26 August 24Maybe you are the first one within reach to make an 8MHz CPU version.
One read screen, one read/write memory per one 4 clocks cycle
That would be doable, but you'd probably have to swap out the original 200nS DRAMs to achieve that.
If you switch from DRAM to SRAM then it would be easy to use a 20MHz Z80 (but would require a redesigned motherboard to be practical).
You could also make performance gains by only issuing the READY signal when it's required. Ie. when accessing the on board RAM. It's not needed when reading ROM, expansion RAM, performing I/O, or any M cycle which doesn't access RAM.
Quote from: retro space on 08:40, 26 August 24You could also add an option for a custom palette.
I'm planning a 9-bit palette, three bits for each colour (512 colours). That will allow plenty of scope for tuning to match original colours. Adding some extra I/O registers to modify the defaults would be trivially easy.
I have original 150ns DRAM.
Quote from: McArti0 on 10:26, 26 August 24I have original 150ns DRAM.
It would be interesting to see it would be possible with 150ns RAM. You'd have to tighten up the timings for the video part of the cycle. The question is whether that leave enough time for the CPU to make two memory accesses. It's probably worth adding that the original multiplexers are also pretty slow. IIRC they take something like 40-50ns to change state.
In the original timings the READY line is pausing the CPU about 75% of the time. Even if you could give the CPU 50% of the cycle that probably only gets you one CPU memory access per cycle at 8MHz, which is no better that you get at 4MHz.
The timings with DRAMs are tight. It really needs SRAM to get any meaningful improvements.
@Bread80GUNHED showed that cpc work with clocks 24/6MHz its 166ns per tick.
In your diagram we can see that CPC needs only 1.5 ticks for CAS to CAS and RAS to RAS. (Fastest)
On this overclocked cpc it is 1.5 *166ns=250ns
In 16/4MHz and standard GA CPC we have RAS-CAS-RAS-CAS-CAS 3read/write per1us
So at 32/8MHz we nead only 4 read/write (4xRAS-CAS) cycle per 1us. (2times soft 2times screen ram)
4x250=1000ns/1us .... :P
@Bread80 This is fascinating. I'm not really that familiar with embedded programming, but I do have a question about code in your
void fsigs_program_init(PIO pio, uint sm, uint offset, uint first_pin) {
for (int i=0;i<6;i++) {
pio_gpio_init(pio, first_pin+i);
}
pio_sm_set_consecutive_pindirs(pio, sm, first_pin, 6, true);
pio_sm_config c = fsigs_program_get_default_config(offset);
sm_config_set_out_pins(&c, first_pin, 6);
pio_sm_init(pio, sm, offset, &c);
}Does loop unrolling provide any advantage, or since it's init it doesn't really matter for blazing fast arm running @ 160mhz?
Quote from: McArti0 on 13:57, 26 August 24@Bread80
GUNHED showed that cpc work with clocks 24/6MHz its 166ns per tick.
In your diagram we can see that CPC needs only 1.5 ticks for CAS to CAS and RAS to RAS. (Fastest)
On this overclocked cpc it is 1.5 *166ns=250ns
In 16/4MHz and standard GA CPC we have RAS-CAS-RAS-CAS-CAS 3read/write per1us
So at 32/8MHz we nead only 4 read/write (4xRAS-CAS) cycle per 1us. (2times soft 2times screen ram)
4x250=1000ns/1us .... :P
But you also need time for the multiplexers to actually change the addresses going into the RAMs. As mentioned above that's 40 to 50 ns per change. Four changes per cycle (CPU/CRTC and address high/address low), which adds 160 to 200ns per cycle.
An 8MHz CPU actually needs RAS-CAS-RAS-CAS-RAS-CAS-CAS. Two full cycles for the CPU, then the sequential access for video.
But an 8MHz CPU is doing one memory cycle per half of the 1us gate array cycle. The second half of that 1us will still be mostly occupied by the video access, with the end result that the CPU will be paused every other memory cycle and not much real gain in performance.
Quote from: Singaja on 14:12, 26 August 24@Bread80
This is fascinating. I'm not really that familiar with embedded programming, but I do have a question about code in your
void fsigs_program_init(PIO pio, uint sm, uint offset, uint first_pin) {
for (int i=0;i<6;i++) {
pio_gpio_init(pio, first_pin+i);
}
pio_sm_set_consecutive_pindirs(pio, sm, first_pin, 6, true);
pio_sm_config c = fsigs_program_get_default_config(offset);
sm_config_set_out_pins(&c, first_pin, 6);
pio_sm_init(pio, sm, offset, &c);
}
Does loop unrolling provide any advantage, or since it's init it doesn't really matter for blazing fast arm running @ 160mhz?
There's probably a function which can initialise multiple pins in one go, but I've not bothered to look up what it's called. In any case, this is code which only runs once at startup.
If I really cared about performance I'd be writing directly to hardware registers. The built in functions are all slowed down by parameter validation and generalised code.
I think we're misunderstanding each other, I'm talking about another new GA with different timing. How can you talk about a small increase in performance when the bandwidth of soft RAM increases x2. Mips cpu increases x2 too.
Quote from: McArti0 on 15:32, 26 August 24I think we're misunderstanding each other, I'm talking about another new GA with different timing. How can you talk about a small increase in performance when the bandwidth of soft RAM increases x2. Mips cpu increases x2 too.
Quite probably there's a misunderstanding somewhere.
With original hardware and DRAM I think there's little opportunity for improvement. A faster CPU is still constrained by the amount of time required for the gate array to read it's two bytes of data. With a new main board and SRAM then there's tonnes of potential.
Quote from: McArti0 on 15:32, 26 August 24I think we're misunderstanding each other, I'm talking about another new GA with different timing. How can you talk about a small increase in performance when the bandwidth of soft RAM increases x2. Mips cpu increases x2 too.
Are you thinking of splitting the video data reads? So each 1ms cycles becomes two 500ns cycles, with on CPU access and one video access per (half) cycle? That might well be doable. Each (half) cycle would then be two memory accesses plus four multiplexer updates. The best case timing there is 2x160ns for memory and 4x40ns for multiplexers, a total of 480ns. Might be possible but very tight.
BTW the original specced RAM is 200ns. 160ns is not twice as fast.
Quote from: Bread80 on 17:23, 26 August 24160ns is not twice as fast.
doesn't have to.
The catch is that in the standard 4MHz CPC you read the memory 3x per 1us.
And in the 8MHz version not 6x per 1us but only 4x per 1us
only 1,33x more ...
but GUNHED showed that cpc work overclocked 1,5x
Quote from: McArti0 on 17:34, 26 August 24Quote from: Bread80 on 17:23, 26 August 24160ns is not twice as fast.
doesn't have to.
The catch is that in the standard 4MHz CPC you read the memory 3x per 1us.
And in the 8MHz version not 6x per 1us but only 4x per 1us
only 1,33x more ...
but GUNHED showed that cpc work overclocked 1,5x
I remember looking into this many years ago (just overclocking, not a new GA architecture). Overclocking is possible, but there are issues with reading disks and some restrictions on how you can use the AY and read tapes too. It's an interesting idea anyway.
With the idea you're suggesting, it may be easier to resolve disk issues etc, but from a first glance, I think it will be extremely difficult to get the timing exactly right and it would probably require new firmware (to slow down the routines) to sync the CPU with the FDC and tape reading, which are essentially hardwired to use the CPU clock for timing.
Bryce.
If you do it through RP2350 you can do it as a turned on and off speedstep by port 3FFF. Like Normal/Turbo.
ps. I was also thinking about starting to make some ED 00-3F orders because they are free in Z80.
Quote from: McArti0 on 17:34, 26 August 24Quote from: Bread80 on 17:23, 26 August 24160ns is not twice as fast.
doesn't have to.
The catch is that in the standard 4MHz CPC you read the memory 3x per 1us.
And in the 8MHz version not 6x per 1us but only 4x per 1us
only 1,33x more ...
but GUNHED showed that cpc work overclocked 1,5x
I'll try arguing my point from a different direction.
A Z80 memory cycles takes four clock cycles. (Typically) two clocks for refresh and two for memory access. The original gate array timings use (roughly) two of those four clocks for reading video data. The CPU is put in a wait state during those video reads but much of that waiting is during the refresh part of the cycle, so doesn't actually slow down the CPU.
If you up the CPU speed to 8MHz and you now get 8 CPU clocks per gate array cycle. If you dedicate the same amount of time to video reads you end up with four clocks for the CPU and four clocks for the video read. Since the CPU still takes four clocks to execute a memory cycle you get four cycles when the CPU is executing and four when it is paused. The end result being that you still only get one CPU instruction executed per gate array cycle.
If you're using 160ns DRAM then you can obviously shorten the length of time required for video reads. It's possible that this period is now short enough that the CPU can now execute two memory cycles per gate array cycle - one operating unimpeded, the other stretched with wait states, but my gut feeling is that there is still not enough time for the CPU to execute two full cycles per gate array cycle.
I'm not saying that it *can't* be done. I'm just saying that *I* don't think it is possible, but I'm happy to be proved wrong.
The only way to answer the question is for someone to sit down with the relevant data sheets (160ns DRAM, multiplexers, Z80, HAL etc) and draw up a timing diagram to see how it pans out.
Quote from: Bread80 on 11:32, 27 August 24If you up the CPU speed to 8MHz and you now get 8 CPU clocks per gate array cycle. If you dedicate the same amount of time to video reads you end up with four clocks for the CPU and four clocks for the video read. Since the CPU still takes four clocks to execute a memory cycle you get four cycles when the CPU is executing and four when it is paused. The end result being that you still only get one CPU instruction executed per gate array cycle.
Here you are making a mistake of adding in memory without paper and pencil.
New timing is simple.
Ras-cas for soft
Ras-cas for video 2+2
Ras-cas for soft
Ras-cas for video 2+2
Sum=8
Imagine you are doing GA to CPC with a throughput of 1MB video per second. Hsync 7,8kHz, Vsync 25Hz.
You change the video ras-cas-cas to ras-cas.
Something like that....
And error. Left mod READY is longer than nMREQ :-X
But mayby no error?
Quote from: McArti0 on 09:21, 28 August 24Something like that....
As I mentioned above, show me something with *timings* and I might be willing to accept it. Until then it's just a theory.
BTW this is the timing diagram I use these days. If shows not just the signal timings but also the update delays for the relevant ICs.
I can share the original SVG if you like, but the forum software won't let me upload it.
Yes, quite some file formats need to be ZIPped to be uploaded.
ZIP is accepted by forum
Here's the zipped SVG. It was created with Inkscape, if that makes any difference.
@Bread80 datasheet 4164-15 say that full cycle is 270ns.
270x2=540>500
it's tight, very tight.
Nice work. It looks like that may well work. But, one fly in the ointment: /CPU_ADDR is also the clock for the AY sound chip.
Quote from: Bread80 on 12:29, 04 September 24But, one fly in the ointment: /CPU_ADDR is also the clock for the AY sound chip.
Bushnel or Alcorn used to say that if something doesn't work properly, he called it a feature. ;D
This is a feature to make Atari ST mods work. :laugh:
Ps. AY in Spectrum 1.77MHz , AY (Yamaha) in Atari ST - 2MHz
Part 3: The 'conditional signals' (/244EN, /MWE and /CAS) which are asserted for a portion of the gate array cycle only if an input pin is asserted (or de-asserted). https://bread80.com/2024/09/16/pico-garry-2350-part-3-csigs-conditional-signals/
Part 4: Triggering the /ROMEN and /RAMRD signals. These depend on the states of /RD, A15 and A14 as well as the upper and lower ROM enable states.
https://bread80.com/2024/11/11/pico-garry-2350-part-4-memory-read-select/
Quotethe port address of the Gate Array is dependent address line A15 (and only A15).
Are you 100% sure? :o
LOGON wrote that A14 must be Hi. ::)
CALL &BCC8: REM disable events
OUT &7FFF,&10: REM GA border
OUT &3CFF,&5F: REM A14=0 and CAN NOT SET BORDER COLOR !!!
all in previews post
Quote from: McArti0 on 19:58, 11 November 24Quotethe port address of the Gate Array is dependent address line A15 (and only A15).
Are you 100% sure? :o
LOGON wrote that A14 must be Hi. ::)
Good point. I've double checked against the reverse engineered schematics, and it does indeed check A14. I'll update the article. Although I suspect it's more a case of having A14 available and it didn't cost anything to include it, given it's the only internal device which checks more than one bit of the I/O address.
@Bread80 where is point/edge when GA read VRAM?
Quote from: McArti0 on 09:59, 13 November 24@Bread80 where is point/edge when GA read VRAM?
No idea. That would depend on the properties of the ULA being used and I'm not even sure if those are publicly available.
For the Pico Garry I use point based on the specs for the DRAMs and the timings of the end of the control signals (ie. CAS[0]) do determine when to sample the bus.
- And (I can't remember) if the multiplexers start to change before the end of CAS then that should also be factored in.