Amstrad CPC WiFi

[Duke]

You'd be bored to death, that's how slow it goes...

What about a live webcam of your factory, to see the progress of the work? 

[CraigsBar]

You'd be bored to death, that's how slow it goes...

*that* I don't believe. A card that sprang from nothing to a fully working WiFi and microsd solution in one step, with further promises to come is awesome. |httpget is a brilliant feature BTW, I love it.

Craig

[SRS]

S, community:  where are the websites with free HTTPGET pictures, programs, sounds, demos - directly to cpc ... 

[CraigsBar]

OK So I do have one question.....


I am sure I read somewhere that the M4 board supported Lower Rom replacement too. Ad if so then this would allow FW 3.15 to be installed.


Is this true or did I dream it?


If I did not dream it, then how do I activate this feature. If not then could it be a feature request to add the Lower Rom to the functionality?


Craig

[dirtybb]

S, community:  where are the websites with free HTTPGET pictures, programs, sounds, demos - directly to cpc ... 

Hi,

Perhaps @hERMOL  from CPC Rulez can help for that.
He did a great software using TotO's Minibooster, called RULEZ!CHARGE

Envoyé de mon iPhone en utilisant Tapatalk

[Executioner]

Hi Duke,

It seems this board is fast becoming the de-facto standard for CPC internet support and some other things like FAT filesystem/DSK support. I have one major concern. Perhaps it's just my misunderstanding, but all the commands seem to return results immediately, including HTTPGET (which is impossible). The ROM simply sends the command then reads the data. Obviously, the data isn't available straight away, and there's no code in the ROM to wait for a response, so how do you force the Z80 to stop and wait. Could it get stuck waiting forever? Are interrupts available while it's waiting? Is the CPC internal RAM refresh still happening as it should be?

[Duke]

@Executioner
How it works is that once a byte is written to port 0xFC00, the M4 will issue a BUSRQ and effectively the z80 will be "stopped" while the M4 processes the command.
Once processed and responses are written, control is let back to the z80.
It could get stuck, if the M4 code crashes (which it shouldn't of course!).
Most responses should be so fast that it's hardly noticeable, but of course doing realtime effects and downloading / doing sd I/O etc, could result in glitches.
If it turns out to be a problem in some way, it could be re-designed to pull a port on the z80 while waiting for it to be processed. Reason for the BUSRQ, is that it cannot maintain romboard emulation while the MCU is doing heavier tasks, so the wait code would then need to be placed in RAM.
As it is though I think it works pretty good atleast for all the basic operations it does now.

Hi Duke,

It seems this board is fast becoming the de-facto standard for CPC internet support and some other things like FAT filesystem/DSK support. I have one major concern. Perhaps it's just my misunderstanding, but all the commands seem to return results immediately, including HTTPGET (which is impossible). The ROM simply sends the command then reads the data. Obviously, the data isn't available straight away, and there's no code in the ROM to wait for a response, so how do you force the Z80 to stop and wait. Could it get stuck waiting forever? Are interrupts available while it's waiting? Is the CPC internal RAM refresh still happening as it should be?

[Duke]

You read right, but it's not ready yet. Next upgrade   - I am not sure what FW 3.15 does, but I think it's designed for XMEM?

OK So I do have one question.....


I am sure I read somewhere that the M4 board supported Lower Rom replacement too. Ad if so then this would allow FW 3.15 to be installed.


Is this true or did I dream it?


If I did not dream it, then how do I activate this feature. If not then could it be a feature request to add the Lower Rom to the functionality?


Craig

[Audronic]

@Duke


Do you have a link to an "Idiots Guide" for the M4 and the amstrad CPC Please.
I have seen the Video. Brilliant.


Thanks   Ray

[Duke]

@Audronic

There is this, that explains the commands/basics:
http://www.spinpoint.org/cpc/m4info.txt

If anything unclear just ask

[Audronic]

@Duke


Thanks.
I had not seen that before.


Ray

[CraigsBar]

You read right, but it's not ready yet. Next upgrade   - I am not sure what FW 3.15 does, but I think it's designed for XMEM?

It's a lower ROM replacement with many added features. It's not just for the xmem, but works with any method or replacing the lower ROM. I have it burned into a plus cart, on a single lower ROM board and in my xmem.

[Executioner]

How it works is that once a byte is written to port 0xFC00, the M4 will issue a BUSRQ and effectively the z80 will be "stopped" while the M4 processes the command.

Well, a HTTPGET for example could easily take seconds to execute. If the BUSRQ is held for that time the Z80 won't be able to do anything else at all? Does this also affect the Gate Array access to the bus for display data?

[Duke]

That's correct. Afaik. gate array and CTRC are unaffected by the BUSRQ, but you probably know this better than me.

Well, a HTTPGET for example could easily take seconds to execute. If the BUSRQ is held for that time the Z80 won't be able to do anything else at all? Does this also affect the Gate Array access to the bus for display data?

[Executioner]

I think the Gate Array has direct overriding access to the first 64K of RAM and will exclude the Z80 and anything else external from using it. The CRTC should generate it's signals so long as it has a clock input, so the display should be safe. I didn't realise the M4 actually needed to be active for the ROM to be available to the Z80 (single core being used for other stuff?) as there's very little extra logic on the board itself, meaning even if the M4 board could do it's own thing without stopping the Z80, you'd need another ROM board if you're running stuff from ROM. Just how fast is the M4, and would there be any way to interleave the network/SD and Z80 ROM access? I'm not sure it's a huge problem as like uPD765 floppy access you can't really do anything else at the time on the CPC.

[dvallet]

hello
i-m interested in one mx4 board with edge connector for cpc 6128 standard.
how add me to the list

[Duke]

The STM M4 is single core @ at 168MHz, most instructions are 1 or 2 clocks (LPC does have some cool ones with both M0 and M4, which would have been ideal I think).
It constantly has to monitor the CPC bus and be ready to respond with very preciese timing.

There is of course workaround to this method. As placing a pull function (read a port and expect a certain value) in ram to see if the M4 is done with its work. As long as external roms aren't used during that period.
But as you said it probably isn't a huge problem atleast not as long as the tasks are downloading/reading/writing data.

If it was to be used as an accellerator for the CPC, I think best method, would be to do CPC RAM emulation on the M4, then you could provide some nasty fast blitter like routines etc

I think the Gate Array has direct overriding access to the first 64K of RAM and will exclude the Z80 and anything else external from using it. The CRTC should generate it's signals so long as it has a clock input, so the display should be safe. I didn't realise the M4 actually needed to be active for the ROM to be available to the Z80 (single core being used for other stuff?) as there's very little extra logic on the board itself, meaning even if the M4 board could do it's own thing without stopping the Z80, you'd need another ROM board if you're running stuff from ROM. Just how fast is the M4, and would there be any way to interleave the network/SD and Z80 ROM access? I'm not sure it's a huge problem as like uPD765 floppy access you can't really do anything else at the time on the CPC.

[Duke]

Send me a pm with your email address, then you will be added to the list

hello
i-m interested in one mx4 board with edge connector for cpc 6128 standard.
how add me to the list

[TotO]

If it was to be used as an accellerator for the CPC, I think best method, would be to do CPC RAM emulation on the M4, then you could provide some nasty fast blitter like routines etc

The question is not new and always the same: When the CPC is no more a CPC?
Taking control over the Z80 with a MCU (your ARM, Arduino, ...) allow everything. The CPC is finally a simple terminal to input and display. 

[Duke]

I completely agree. I prefer the CPC to be the CPC and have some easy methods to external data

The question is not new and always the same: When the CPC is no more a CPC?
Taking control over the Z80 with a MCU (your ARM, Arduino, ...) allow everything. The CPC is finally a simple terminal to input and display. 

[TotO]

I completely agree. I prefer the CPC to be the CPC and have some easy methods to external data

By the way, a blitter is from my point of view the more logical improvement into a "CPC 2" design.
The strange choice made by Amstrad for the PLUS range of computer was dicted by the GX4000 requirements.

[TFM]

If it was to be used as an accellerator for the CPC, I think best method, would be to do CPC RAM emulation on the M4, then you could provide some nasty fast blitter like routines etc

Well, since the CRTC can only access the first internal 64 KB of RAM it would limit additional features.

[TotO]

Well, since the CRTC can only access the first internal 64 KB of RAM it would limit additional features.

I don't know any 8-bit system with 64K VRAM. 

[gerald]

That's correct. Afaik. gate array and CTRC are unaffected by the BUSRQ, but you probably know this better than me.

BUSRQ will just make the Z80 to release the BUS : ADDR/DATA/IORQn/RDn/WRn/M1n will be floating (there is a probability that these signal goes high by themselves thanks to the TTL input their are connected to, but this is not granted)
The video processing (CRTC/GA) is fully autonomous, and do not rely on the Z80 at all, but if you do not drive at least the MREQn/IORQn signal high when the bus is granted, you risk some random access to the RAM due to floating signal.

[Duke]

Makes sense, thanks.