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 8 Guests are viewing this topic.

Gryzor

Quote from: ||C|-|E|| on 16:36, 10 May 16
It would be ridiculously great to have a cool IRC client for the Amstrad that works straight from BASIC  :D


Would actually be pretty functional in mode 2...

||C|-|E||

In mode 2 it would be as great as the old mIRC client regarding chat functionality  :D

Gryzor


||C|-|E||

Now that you mention it... I moved to PiRCH at some point, but I did not remember it at all   :laugh:

Manu

Nice project!

I'm interested in one board :D

ronaldo

@Duke, really nice work. I'd also be interested in 2 cards. There are many development projects waiting for this kind of card :)

Gryzor

[ot]
Quote from: ||C|-|E|| on 16:17, 11 May 16
Now that you mention it... I moved to PiRCH at some point, but I did not remember it at all   :laugh:


That was the geek choice, actually :) [/ot]

Lazy Dude

It's an exiting 'must have for 2016' fashion accessory for the CPC  8)
Yeh I'll be interested in one.

anyf33

Quote from: Duke on 09:18, 11 May 16
@mr_lou
I have ordered some right angle pcb edge connectors. I'll have to see them before I am sure if they can be used for the cpc.
The idea was to make a mini pcb (ie. expansion port length x 2 cm) with edge connector for the cpc expansion port in one side and a idc connector in the other side, this could then be either right angle to lay flat with the table or non angled, so it will standup like ie. ddi interface.
This way users can have their own choice, use motherX4 or cable or use the edge connector to idc connector pcb if they have non centronics cpc.
Lets see how it goes.
About the HxC, this device cannot replace it, as it cannot act as FDC controller, so all games that use custom disc loading (most copy protected discs) talking directly to the FDC will not work. A proper cracked version is needed if it can be found and I have tested quite a few cracks that still have direct FDC loading code.
About fdc loading can be byapassed through cpc compactages versions but he dont have all games of course

Jomicamp

This advancement places the cpc range in the XXI century finally... Connectivity is what better defines a modern computer... This is an important to re-establish its functionality and leave temporary the computer museum...

No doubt that I am also interested in one board Duke! Congratulations!

Duke

#85
Quote from: anyf33 on 22:07, 11 May 16
About fdc loading can be byapassed through cpc compactages versions but he dont have all games of course
Yes, also back in the day there were many cracks of the same games, some better than other, but I think they are hard to find nowadays.

Edit: Actually there is a good collection here : cpccrackers.free.fr
Just managed to find a version of robocop that didn't use direct fdc loading.

hsimpson

@Duke: excelent work  :o .

+1 for me please  :) .

Gryzor

Quote from: Jomicamp on 00:27, 12 May 16
This advancement places the cpc range in the XXI century finally... Connectivity is what better defines a modern computer... This is an important to re-establish its functionality and leave temporary the computer museum...

No doubt that I am also interested in one board Duke! Congratulations!


I don't think requests from non-members can be taken into account man...

villain

Quote from: Duke on 09:18, 11 May 16
About the HxC, this device cannot replace it, as it cannot act as FDC controller, so all games that use custom disc loading (most copy protected discs) talking directly to the FDC will not work. A proper cracked version is needed if it can be found and I have tested quite a few cracks that still have direct FDC loading code.

Probably a silly question but I don't mind... I'm quite well known for being clueless. :-) Wouldn't it be possible to mount a .dsk on the PC, emulate the FDC also on the PC side and send the "read" data via Wifi to the CPC? Ok, going back to my abacus now. :-)

Duke

Quote from: villain on 13:49, 13 May 16
Probably a silly question but I don't mind... I'm quite well known for being clueless. :-) Wouldn't it be possible to mount a .dsk on the PC, emulate the FDC also on the PC side and send the "read" data via Wifi to the CPC? Ok, going back to my abacus now. :-)
In theory it's possible to emulate the FDC directly on the M4, not the PC as there is too much latency for that going via wifi.
The problem is that 664's & 6128's already have a FDC on board, so it would be a conflict with the real fdc.

Duke

Quote from: Gryzor on 12:29, 13 May 16

I don't think requests from non-members can be taken into account man...
Yes I will need a way to get in touch, once the boards start shipping. So Jomicamp please sign up in here or leave a message on my site with your email.

Duke

Speaking of PC, I just made this simple tool today: GitHub - M4Duke/cpcxfer: Cmd line tool to transfer files to and from M4 board

With it you can upload and download files from the M4 board(CPC) from command line on your pc.
Quite handy for crossdevelopment, you can put it into your makefile.

Still needs a bit of work, as I just added header support for ascii files (protext). It can transfer files like DSK images just fine (no header addition/removal needed).

Eduard

+1 board, Duke. Great job !!!

Tolkin

Find it trough Octoates News Site...
Will definitly buy one if possible. So please, one Board for me.
Thanks so much for the cool work
Bye
Tolkin

yannis_uno

I am also interested!


Thanks very much!  :)

jomicamp

Hi again!

Now I am registered. Please, Duke count with me for one of those boards!

This will be a must have for the cpc

Regards to all members of the forum

Duke

#96
Just been improving game compatiblity quite a bit for M4 board.
However I have one issue left (I think).
That is the init message of my ROM, as sometimes there is loaders in the screen ram (&c000) which will be corrupted by it when they re-init the discrom (amsdos is silent).
Of course when I disable the init message they work, however I would like a method where I can detect if it was a common reset (some var in ram) or just re-init rom, so I would only display the message on cold boot (easy) and reset. Alternative is |m4msgoff or not display the message at all. The later I don't like that as you would like to know if its there or not.

Anyone have an idea for a detection mechanism?

EDIT: I just had an idea, I could checksum a certain part of the "(c)1984 Amstrad Consumer Electronics plc" in screen memory to detect if it was a reset, not ideal. But should work assuming some part is always the same regardless of model/language.

Etegar

+1 Board, please !
Many thanks for this new CPC's device, Duke.

Grim

Quote from: Duke on 19:33, 14 May 16Anyone have an idea for a detection mechanism?
Well, you could use the system's TIME value which is zeroed when the Firmware initializes itself. And its value when the Firmware begins to walk through all the ROMs is still somewhat "little". I think it might be better than some sort of checksum, but still is a fuzzy detection mechanism.

The detection routine would be something like this:
; Get TIME pointer depending on the Firmware version
ld hl,&B8B4+3 ; v2+
ld de,&B184+3 ; v1
ld a,(&BC1E)
cp 169
jr nz,$+3
ex de,hl

; Check the TIME value
ld a,(hl)
dec l
or (hl)
jr nz,quiet
dec l
ld a,(hl)
cp 2
jr nc,quiet
; TIME < &00000200
; Assume we've been called during system initialization
; Display some fancy boot message here
; ...

quiet
; TIME >= &00000200
; Assume we've been called manually by some program
; Do not print anything to screen
; ...

Duke

#99
Cool!  Thanks a lot, seems a much better solution.
I will try it out.

EDIT:
Tested it. Unfortunately it fails to work with some of the "problem" games, as they appearently re-init more than rom7.
Also at the time of the rom walk the time value is 0, which of course was fine.
Eitherway for now I just check if the COPYRIGHT character is on the screen, line 4, column 2 and it seems to do the job.

Quote from: Grim on 18:20, 15 May 16
Well, you could use the system's TIME value which is zeroed when the Firmware initializes itself. And its value when the Firmware begins to walk through all the ROMs is still somewhat "little". I think it might be better than some sort of checksum, but still is a fuzzy detection mechanism.

The detection routine would be something like this:
   ; Get TIME pointer depending on the Firmware version
   ld hl,&B8B4+3 ; v2+
   ld de,&B184+3 ; v1
   ld a,(&BC1E)
   cp 169
   jr nz,$+3
    ex de,hl

   ; Check the TIME value
   ld a,(hl)
   dec l
   or (hl)
   jr nz,quiet
   dec l
   ld a,(hl)
   cp 2
   jr nc,quiet
   ; TIME < &00000200
   ; Assume we've been called during system initialization
   ; Display some fancy boot message here
   ; ...

quiet
   ; TIME >= &00000200
   ; Assume we've been called manually by some program
   ; Do not print anything to screen
   ; ...


Powered by SMFPacks Menu Editor Mod