Chibi Akumas Episode 2: Confrontation! [game for CPC then MSX2]

Página 2/9
1 | | 3 | 4 | 5 | 6 | 7

Por keith56

Master (162)

Imagen del keith56

23-09-2017, 03:26

Manuel wrote:

keith, which MSX2's did you buy? (Are you sure you need that many? I would expect only one is needed, unless you go really close to the edge, like some demos.... anyway, the rest of the variations (like memory configurations) can be easily tested on a good emulator.)

I have:
Panasonic A1
Panasonic A1MK2
Panasonic A1-F
Sony HitBit HB-F1-XD
Sony HitBit HB-F1II
Sony HitBit HB-F1XDJMSX2+

Yeah I probably have too many, but with the exception of my 1st I've picked them all up faulty & pretty cheap , and repaired the floppy drives/keyboard membranes etc - I get a kick out of repairing them, and it feels like an 'investment' of sorts!
almost all my development is on Emulators, but I had a big problem late on with the original CPC game which didn't occur on the emulators (a buggy palette switch command was wiping disks!!!) so I want real hardware to test on - and as one of my CPC's has just suffered a memory failure, the more the merrier!... ChibiAkumas only uses the CPC firmware during loading - I won't be using the firmware during gameplay on MSX - it's just too much avoidable slowdown and with over 255 objects moving on each frame, I have to be as fast as I can make things reliably work - I don't know how 'close to the edge' that counts!

Por sd_snatcher

Prophet (3517)

Imagen del sd_snatcher

23-09-2017, 04:34

Your game will be very welcome in the MSX2, keith56! I just watched the videos and it seems really fun. Smile

Here goes some development tips:

- Take some time to read the MSX Compatibility testing wiki article. It has some valuable tips to avoid headaches
- The 6 MSX models you purchased have very similar memory layouts. But keep in mind that on the wild there are a lot of different configurations
- The CPC, ZX-Spectrum and C64 machines have very little variation in their hardware specs. Each machine behave almost an exact clone of each other. OHOT, the MSX has a wild variation in hardware. Even the timings to access the VDP vary from different models.
- I heartily recommend you to use openMSX for the development. It might be a bit harder to learn in the beginning, but that certainly pays off because of its excellent debugging features, large variety of machines supported, constant improvement and fantastic development team.

Por Grauw

Ascended (10605)

Imagen del Grauw

23-09-2017, 12:25

keith56 wrote:

I'll be posting a few times a week on my twitter feed here, with screenshots and grumblings on how things are going: twitter.com/keith009988

Awesome, followed!

keith56 wrote:

If it's not too much of a bore, I would like to post on this forum once or twice a month with progress on how things are going as well as asking for advice if I'm getting stuck

Never a bore! I love those type of threads here. Big smile

keith56 wrote:

almost all my development is on Emulators, but […] I want real hardware to test on

I wrote something here but I see sd_snatcher pretty much already wrote the same Tongue. In short, I recommend openMSX, it’s accurate and allows you to test many machines with out-of-the-ordinary configurations easily. The variety of machines is where MSX is pretty different from other platforms. But at the same time, if you know where things can vary the machines are generally also pretty consistent. There are few differences which can be qualified as “bugs”.

Por keith56

Master (162)

Imagen del keith56

23-09-2017, 14:13

I'm using OpenMSX, thanks for that bit of advice! Ok, I see that I need to be careful about memory slot handling....

1. I'll only be 64k of internal ram, only be supporting 64k machines , and I only plan to use the firmware for disk operations.
can anyone point me to the most compatible way to switch all 64k of ram into the address space - turning off the roms

the test code I'm using so far uses DBASIC (&F37D) - how does this cope with paged ram - does it switch it's disk roms back on, or do I have to do it - can it load to any ram bank, or only the ones not in the way of the disk rom?

2. If I need to switch the roms back on for DBASIC to work, can someone advise how to undo what I asked in question 1!!

I know these are probably really dumb questions - sorry, but an answer from someone who knows will probably save me a day or two of head scratching!

Por Grauw

Ascended (10605)

Imagen del Grauw

23-09-2017, 16:04

keith56 wrote:

1. I'll only be 64k of internal ram, only be supporting 64k machines , and I only plan to use the firmware for disk operations. Can anyone point me to the most compatible way to switch all 64k of ram into the address space - turning off the roms

Make your game for MSX-DOS Smile. That’s the easiest way. The “BIOS” environment (MSX-BASIC / ROM) is mostly aimed at keeping the BIOS in page 0, e.g. the interslot calls are there and expected to always be present by various hooks. If you want to page RAM there, then it makes more sense to use DOS.

Generally speaking, switching page 0 is avoided although possible with some headaches, and switching page 3 is pretty much impossible, it will cause severe problems with the BIOS, so not done at all.

p.s. the common term in the MSX world for the firmware is “BIOS”. Firmware usually refers to manufacturer-specific built-in software (some machines have a word processor or something like that).

keith56 wrote:

the test code I'm using so far uses DBASIC (&F37D) - how does this cope with paged ram - does it switch it's disk roms back on, or do I have to do it - can it load to any ram bank, or only the ones not in the way of the disk rom?

It does an interslot call, so whatever slot was there will be automatically switched back. I seem to recall that in the MSX-BASIC / ROM environment you can not load directly into RAM which is in page 1, but in the MSX-DOS environment you can.

keith56 wrote:

2. If I need to switch the roms back on for DBASIC to work, can someone advise how to undo what I asked in question 1!!

Note that the interslot call is an RST in the 0-100H area of the BIOS and MSX-DOS environment, so that won’t work if you page in some arbitrary RAM there. In MSX-DOS it’s been set up correctly to work without problems. Btw, in MSX-DOS the BDOS entry point is 5H rather than F37DH.

keith56 wrote:

I know these are probably really dumb questions - sorry, but an answer from someone who knows will probably save me a day or two of head scratching!

No, not at all Smile. It takes us who are familiar with the system just a few minutes, and can save you a lot of time!

On the topic of bare-to-the-metal programming, it is pretty commonly done for VDP and PSG access, etc. But I would recommend to use the BIOS for most other things, like slot switching (complicated to do manually and easy to introduce incompatibilities), disk access (you must, for compatibility), interrupt handler[1], etc. Being selective about what you access directly will let you get high performance while saving you a lot of compatibility headaches between all the different MSX machines and generations.

[1] About custom ISR, the primary way to do this is using the hooks (during which page 0 is always the BIOS). One can also replace the entry point fairly easily in DOS for faster interrupt response time if needed, but beware that it will be switched out during BIOS / BDOS calls so it will hang if e.g. a line interrupt occurs then. And call the original ISR after, to avoid issues like ever-spinning drives.

Por ARTRAG

Enlighted (6846)

Imagen del ARTRAG

23-09-2017, 16:19

The best option nowaday is to develop a cartridge using any of the mappers supported by openmsx.
If your game constantly needs to work in 64KB of ram you can switch the cartridge slot back and forth using it as it was a disk.

Por santiontanon

Paragon (1639)

Imagen del santiontanon

23-09-2017, 18:53

Nice!! I'd also be interested in reading regular updates! So, we are all waiting! Smile

Por JohnHassink

Ambassador (5605)

Imagen del JohnHassink

23-09-2017, 22:18

The general design looks very pretty and quite original. Also, if it already looks this cool with only 4 colours, the MSX2 version is something to really look forward to.

Por keith56

Master (162)

Imagen del keith56

24-09-2017, 00:32

Lots of good advice here! thanks for this!
I think maybe I should clear up something about the game and the way it diskloads - as it may alter the advice people give.

on the CPC the game works in 2 modes.

1. Loading mode - firmware is enabled, custom interrupt handler is disabled - data is loaded into ram as required
2. Gameplay mode - firmware is disabled, all roms are paged out - custom interrupt handler is enabled and all key/joy/sound/graphics are done by my code - the firmware/bios will not be used in any capacity.

it doesnt' matter to me where the ram banks are mapped on the address space during disk load, provided I can write to them in some way - also, I only load in <16k blocks, so I only need to write to one at a time... based on this, is MSX-Dos needed, or is BDOS capable of doing what I need.

Also, I don't think the question I asked before was quite answered - if the ram banks can be in different slots on different MSX models, how do I detect where they are so I can use them in a compatible way?

Por sd_snatcher

Prophet (3517)

Imagen del sd_snatcher

24-09-2017, 05:55

I'll talk from my personal experience here. Others might think differently.

Since this you already state the following conditions and restrictions:

1) It's your first MSX game
2) You want 64KB of RAM
3) You hand to be able to easily handle the interrupts

My advice is to go for a .COM MSX-DOS development, for many reasons:

  • The MSX-DOS abstracts all the RAM management for you. No need to search where it its. No risk of incompatibilities with weird layouts. On MSX Turbo-R, there will be no risk of selecting a slower external RAM instead of the fast internal RAM. On MSX-DOS2/Nextor, there will be no risk of artificially selecting some other weird RAM that is not the system RAM and end up not being able to use the disk to load the next stages.
  • Faster line interrupt handling is easier to implement, provided that you daisy chain the interrupts back to the system so it can handle the other types of interrupts. Software that don't do that are on the risk of having incompatibilities with other extensions. It not only inelegant to ask the user to remove their MSX-Audio, RS-232 or whatever: in some machines some of these extensions are built-in. Always keep in mind that the MSX is a proper standard somewhat like a modern Android, with lots of extensions and a wild variety of different hardware. All of that in an 8-bit machine. It's like a miniature of a modern system. Smile
  • As a bonus, hard-disk (and other mass storage devices) install will be a piece of cake and everyone will be happy. Wink

Some additional hints:

  • The MSX has a plethora of devices that can be connected to the joystick ports, like joypads, mice, trackballs, touchpads, paddles, light guns, Music tablets, etc. All of them have different protocols, and the BIOS can handle them transparently. If you kick the BIOS away in gameplay mode, you'll have to worry about that too, otherwise the annoying "you must disconnect that device" problem will arise again. The best approach is to use the BIOS only on vertical interrupts to read the joystick status and save it on some variables so your game can access them later
  • Turbo support is always welcome. Since your game is a bullet hell shmup, turbo will make it run even smother Smile
  • Screen-5 resolution is in fact 256x212. But you can reduce it to 256x192 to make the blitter run faster. There are other things that accelerate the blitter even more: disabling the hardware sprites and running the video on PAL mode (50Hz). But it's not advisable to restrict it to 50Hz, since quite some people have monitors that only support 60Hz.
  • If you use the BIOS in your PSG replayer, your game will be compatible with some nice utilities that are only possible in the MSX, like NandemoSCC and NandemoFM.
  • Since you opted for the MSX2, the horizontal smooth scroll trickier to master than on an MSX2+. Take a look here and here for beautiful examples with source code made by ARTRAG on how to implement it. And this one even has parallax and animated backgrounds.
Página 2/9
1 | | 3 | 4 | 5 | 6 | 7