News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Duke

Amstrad CPC WiFi

Started by Duke, 07:36, 07 May 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Duke

You'd be bored to death, that's how slow it goes... :)
Quote from: SOS on 13:51, 29 June 16
What about a live webcam of your factory, to see the progress of the work?  ;D :laugh:

CraigsBar

Quote from: Duke on 14:36, 29 June 16
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
IRC:  #Retro4All on Freenode

SRS

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

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

IRC:  #Retro4All on Freenode

dirtybb

#379
Quote from: SRS on 21:46, 29 June 16
S, community:  where are the websites with free HTTPGET pictures, programs, sounds, demos - directly to cpc ...  :D

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.

Quote from: Executioner on 01:12, 30 June 16
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?
Quote from: CraigsBar on 22:32, 29 June 16
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
Procrastinators Unite,
If it Ain't Broke PLEASE Don't Fix it.
I keep telling you I am Not Pedantic.
As I Live " Down Under " I Take my Gravity Tablets and Wear my Magnetic Boots to Keep me from Falling off.

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
Procrastinators Unite,
If it Ain't Broke PLEASE Don't Fix it.
I keep telling you I am Not Pedantic.
As I Live " Down Under " I Take my Gravity Tablets and Wear my Magnetic Boots to Keep me from Falling off.

CraigsBar

Quote from: Duke on 05:40, 30 June 16
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.
IRC:  #Retro4All on Freenode

Executioner

Quote from: Duke on 05:37, 30 June 16
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.
Quote from: Executioner on 12:49, 30 June 16
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 :)

Quote from: Executioner on 13:20, 30 June 16
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 :)
Quote from: dvallet on 13:26, 30 June 16
hello
i-m interested in one mx4 board with edge connector for cpc 6128 standard.
how add me to the list

TotO

#393
Quote from: Duke on 13:32, 30 June 16If 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.  ;)
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Duke

I completely agree. I prefer the CPC to be the CPC and have some easy methods to external data :)
Quote from: TotO on 13:40, 30 June 16
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

Quote from: Duke on 13:42, 30 June 16I 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.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

TFM

Quote from: Duke on 13:32, 30 June 16
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.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

TotO

Quote from: TFM on 16:20, 30 June 16Well, 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.  ;D
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

gerald

Quote from: Duke on 13:08, 30 June 16
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.

Powered by SMFPacks Menu Editor Mod