News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Recent posts

#1
Quote from: HAL6128 on Today at 20:28Hm, maybe I was a little too fast with my assumption. I thought that the MegaFlash could also replace the Lower ROM, but it seems that it doesn't. So, the Firmware ROM ( X-MEM - CPCWiki ) won't be usable (which initialize ROMs 0-31).
How about using UniDOS as an IDE interface driver? Which interface do you use?
I prefer cubemdos because most easy to use... I'm using a cpc6128 and  a megaflash that could be able to replace the rom 0 (but not the dos rom 7) . But seems that cubemdos and 32rombooster rom can't live togheter ...
#3
Quote from: dodogildo on Today at 14:48
Quote from: GUNHED on Today at 13:54And I remember the games from Bollaware:

- Back Land
- FresFighter
Wow both are great!!
Yeah, Bollaware is great!
#4
Hm, maybe I was a little too fast with my assumption. I thought that the MegaFlash could also replace the Lower ROM, but it seems that it doesn't. So, the Firmware ROM ( X-MEM - CPCWiki ) won't be usable (which initialize ROMs 0-31).
How about using UniDOS as an IDE interface driver? Which interface do you use?
#5
Quote from: HAL6128 on 14:34, 01 May 24Don't know about the Problem, but instead of using the old Booster Rom you could try the more modern Firmware Rom 3.15 / 3.16?
Can you tell me more please?
#6
North & South
Back to the Future 2
Switchblade
#7
Quote from: GUNHED on Today at 13:45
Quote from: HAL6128 on Yesterday at 20:26Interesting! I don't know, but has been CP/M prepared in the past for such kind of things (mounting activities) or did you change something?
CP/M Plus natively supports devices up to 16 MB. In addition it's the only native CPC OS which allows to use the full power of the Z80 - means use 2nd register set. This can speed up applications up to 30%-40% compared to a Z80 which does waste the 2nd register set for f.e. interrupt handling like the native OS (you see, they worked on 8080 before). Since CP/M 2.2 is using the Firmware as BIOS it also doesn't allow to use the genius 2nd register set sadly.
I was thinking more about "mounting" a device during runtime. I understand that a floppy or drive will be recognized and mounted by CP/M during the boot process, but it seems that is also possible after that process; some kind of "hot-plug-in". Tables / internal device lists have to be adapted... ? (It's obviously that I don't understand the CP/M system architecture :) )
#8
avatar_vasilisk
Games / Re: The Key, a A "full" point ...
Last post by vasilisk - Today at 18:49
With careful observation it is easy to solve...  :D
#9
Quote from: cpcoldie on Yesterday at 22:52I've tinkered a "rom-box" and can confirm the rom version works.
I forgot to mention: "...for the uIDE interface".
#10
T
Programming / Re: CPCTelera 1.5 Decrunching ...
Last post by Typhon - Today at 18:29
Quote from: Arnaud on Yesterday at 06:33Hi,
i think @ervin is right, the decompression is overwriting the stack.

To solve your problem try to set the size of your image to 0, 0 (image size by default) and no args after image:
$(eval $(call IMG2SP, CONVERT        , img/transition.png, 0, 0, transition, , ))

I have done this some weeks ago and the size file was OK.


I can confirm that works! Thank you!

// File 'src/transition.h' generated using cpct_pack
// Compresor used:  zx7b
// Files compressed: [ 'tmp/transition.bin' ]
// Uncompressed:    16384 bytes
// Compressed:      612 bytes
// Space saved:      15772 bytes
//
#ifndef transition_612_H
#define transition_612_H
// Declaration of the compressed array
extern const unsigned char transition[612];
// Address of the latest byte of the compressed array (for unpacking purposes)
#define transition_end (transition + 612 - 1)
// Compressed and uncompressed sizes
#define transition_size_z 612
#define transition_size 16384
#endif
Powered by SMFPacks Menu Editor Mod