thp wrote:

Here's a 8086-compatible build (the "normal" builds are usually 80386 builds), r28 should work on any x86, and it should work without EMU386, maybe that brings some performance boost.

Thanks also from me for that 8086-compatible build! Maybe it brings a little performance boost, not sure.
Thing is, the 286 might benefit (-in theory-) from some of the newer real-mode instructions found in the 386 build.
If that's the case, EMU386 perhaps isn't that of a performance killer. Anyway, I don't know anything about the game's code.
NEC20/30, 80186 and 80286 do support a few useful instructions the original 808x is missing. In theory, at least. 😀

Edit: Now that I think of it, some vintage compilers, such as Power C, did offer an 80186 compiler option.
Such a binary would run on 186/286 and the NECs; it would be interesting to see how such a binary would
perform on a NEC20/30 or 80286 in comparison to a pure 8086-build.

- These are just my thoughts, though. It's not another feature request.
Two builds (16-/ "32"-Bit or PC/XT and AT) are enough for everyone, I think. ^^

thp wrote:

Did you set your MT-32 to map the channels so that the first channel is also used? I read somewhere that by default, MT-32 ignores the first channel and just uses the second channel onwards

I'm sorry, no I didn't. I hooked-up everything in a rush and didn't consider this. 🙁
All I tried so far was to make sure the SB-MIDI code works and that the MT-32 received the MIDI signals.
Next time, when I got/found a second audio adapter, I'll try it properly. 😀

thp wrote:

Did you set your MT-32 to map the channels so that the first channel is also used?
I read somewhere that by default, MT-32 ignores the first channel and just uses the second channel onwards.

Hi again, I think I've found what you were referring to.

Note: the first thing to do upon turning on the MT-32 is to press "MASTER VOLUME" and the "5" part button at the
same time, press the "1" part button. This will reset the MIDI channels one through eight,
and when playing - typically - from a MIDI keyboard set to channel 1, it will play.
If you don't do this, you're not going to be able to hear anything because for some odd reason
the MT-32 factory MIDI configuration sets part one to MIDI channel 2. Channel 1 has mysteriously disappeared.
Source: http://www.synthmania.com/mt-32.htm

Update. It was quite some work, but I finally found and
set up my CM-64 that I had boxed up a while ago..

Firstly, I tried to remap my CM-64 for GM (video)..

Afterwards, I played Loonies 8086 r28.
https://youtu.be/9iS1SdpgEZ4

I'm still not sure if the music played the way it should, though. 😕
How many channels does Loonies use for MIDI, by the way ?

The GM patch should -in theory- remap the first 10 channels of the LA portion.
However, channels 11 to 16 are handled by the PCM unit..
Not sure if these extra channels get in the way somehow.

Sorry, that's all I can do so far. I have little experience with General MIDI.

Jo22 wrote:

I'm still not sure if the music played the way it should, though. :confused: How many channels does Loonies use for MIDI, by the […]
Show full quote

I'm still not sure if the music played the way it should, though. 😕
How many channels does Loonies use for MIDI, by the way ?

The GM patch should -in theory- remap the first 10 channels of the LA portion.
However, channels 11 to 16 are handled by the PCM unit..
Not sure if these extra channels get in the way somehow.

Sorry, that's all I can do so far. I have little experience with General MIDI.

Thanks for the test again! Loonies uses MIDI channel 1 and 2 for melody + bass and channel 10 for drums.

The music doesn't sound fully the way it should (in terms of timing, that is - the instrumentation is good; for General MIDI, anyway.. the OPL-2 sounds much more "authentic" retro IMHO), the 286 might just be a bit too slow together with the VGA and the current code.

thp wrote:

The music doesn't sound fully the way it should (in terms of timing, that is - the instrumentation is good; for General MIDI, anyway.. the OPL-2 sounds much more "authentic" retro IMHO), the 286 might just be a bit too slow together with the VGA and the current code.

Thank you, too. I have little experience with remmaping or sending SysEx commands..
If I can find another plug from ~6.2" jack to rca, I can -and will- do a proper MT-32 recoding for you.
At the moment, however, It's quite a mess at home (incl. family trouble). So there's lots of "homework" that still has to be done.

As for the 286, I completely agree. The machine itself is quite quick for what it is, surprisingly.
But it does neither have any shadow RAM, not a fast graphics card. I suspect the OTI-037c to be the culprit.
It's a nice, pure VGA card with emulation modes (CGA, Hercules, EGA), but also very slow.
The whole VGABIOS has to be read over the ISA-Bus each time, for example. In a similar fashion, the system BIOS has to.
In theory, it would be possible to install faster Flash-ROMs, that do not impose a slow access time of 120ns.
But then, the comparison to your older builds is gone and we don't see the improvements anymore. 🙁

Edit: I've made another video with my Casio Casiotone CT-460, a pre-General MIDI keyboard.
The Keyboard was quite popular in late 80s and got support in some Sierra games, along with the MT-540 and CSM-1 Sound Module.
(Incomplete list. A few more Casio Keyboards shared their synth engines.)

Edit: Video uploaded to https://youtu.be/wUxudndvUE8
Please don't get upset if the music sounds funny to you; keep in mind the video is just for fun.. 😀

Coming back to your suggestion of compiling with 286 enhancements, this next build (r29) now comes with the instruction set for 80286 (see screenshot, in Borland C++ 3.1), maybe this also helps a bit.

Here's what's changed since r28:

• Slightly overhauled hardware setup screen, should reduce flickering due to overdraw (not completely gone yet)
• Introduce new machine speed options, 286 option now turns off even more effects/drawing
• Music keeps playing in pause mode ("p" key during gameplay) -- this way, music gets 100% CPU (for testing)

I'm starting to wonder if the palette updates or the VGA-waiting might be causing slowdowns. Or if in the case of your card, if the VGA memory is just really slow and with all the cycle eaters, it might be more performant to double-buffer the screen and then just "rep movsd" it to the VGA framebuffer.

Edit: By the way, Wikipedia's "Intel 80186" page has this to say about the instruction set:

A few new instructions were introduced with the 80186 (referred to as the 8086-2 instruction set in some datasheets): enter/leave (replacing several instructions when handling stack frames), pusha/popa (push/pop all general registers), bound (check array index against bounds), and ins/outs (input/output of string). A useful immediate mode was added for the push, imul, and multi-bit shift instructions. These instructions were also included in the contemporary 80286 and in successor chips. (The instruction set of the 80286 is exactly the instruction set of the 80186 with instructions added only for operations related to the 80286 Protected mode.)

thp wrote:

I'm starting to wonder if the palette updates or the VGA-waiting might be causing slowdowns. Or if in the case of your card, if the VGA memory is just really slow and with all the cycle eaters, it might be more performant to double-buffer the screen and then just "rep movsd" it to the VGA framebuffer.

Wait... are you using Mode X with multiple pages? Then you can double buffer without rep mov. Much more efficient. But requires a bit more complicated drawing routines.

root42 wrote:

Wait... are you using Mode X with multiple pages? Then you can double buffer without rep mov. Much more efficient. But requires a bit more complicated drawing routines.

No, I'm just using plain mode 13h chained mode at the moment. Maybe I'll make the switch to Mode X, but it's a bit more complicated.

thp wrote:

root42 wrote:

Wait... are you using Mode X with multiple pages? Then you can double buffer without rep mov. Much more efficient. But requires a bit more complicated drawing routines.

No, I'm just using plain mode 13h chained mode at the moment. Maybe I'll make the switch to Mode X, but it's a bit more complicated.

Do it! It's not that hard and soooo much more efficient with the page flipping. You just have to rethink your redraw code. You only have to redraw small portions of your game screen anyway.
Pixel plotting can be wrapped in a small macro or inline function, due to the weird addressing in mode X.

root42 wrote:

Do it! It's not that hard and soooo much more efficient with the page flipping. You just have to rethink your redraw code. You only have to redraw small portions of your game screen anyway.Pixel plotting can be wrapped in a small macro or inline function, due to the weird addressing in mode X.

I might give it a try, but my free time is limited, definitely will read up on the Abrash book some more. The page flipping makes things a bit more difficult actually, because some parts of the code assume that the previous frame is still there, so would have to be adapted a bit for page flipping (each frame is drawn over the "second oldest" (the frame before the previous) frame).

But for now, I've added level progression this evening and cleaned out some dead code, so here's kind of the second "public" release (I'll also update the first post of this thread) of the game, it's grown to 16 KiB (compressed EXE, using apack), but it has support for two different sound playback methods (OPL-2 and MIDI) + two new soundtracks (one by Tim Samoff, one by me) compared to the original 8 KiB release, so I think it's quite an improvement.

Thanks to all the people in this thread for helping with testing on real hardware, especially 286 machines and obscure MIDI devices 😉 I thought about ripping out MIDI support to try to get it down to 8 KiB again, but it's just not worth it, and the doubling in size is hopefully more than made up for by the fact that there's now proper music and different output options for sound card fans..

thp wrote:

I might give it a try, but my free time is limited, definitely will read up on the Abrash book some more. The page flipping make […]
Show full quote

root42 wrote:

Do it! It's not that hard and soooo much more efficient with the page flipping. You just have to rethink your redraw code. You only have to redraw small portions of your game screen anyway.Pixel plotting can be wrapped in a small macro or inline function, due to the weird addressing in mode X.

I might give it a try, but my free time is limited, definitely will read up on the Abrash book some more. The page flipping makes things a bit more difficult actually, because some parts of the code assume that the previous frame is still there, so would have to be adapted a bit for page flipping (each frame is drawn over the "second oldest" (the frame before the previous) frame).

But for now, I've added level progression this evening and cleaned out some dead code, so here's kind of the second "public" release (I'll also update the first post of this thread) of the game, it's grown to 16 KiB (compressed EXE, using apack), but it has support for two different sound playback methods (OPL-2 and MIDI) + two new soundtracks (one by Tim Samoff, one by me) compared to the original 8 KiB release, so I think it's quite an improvement.

Thanks to all the people in this thread for helping with testing on real hardware, especially 286 machines and obscure MIDI devices 😉 I thought about ripping out MIDI support to try to get it down to 8 KiB again, but it's just not worth it, and the doubling in size is hopefully more than made up for by the fact that there's now proper music and different output options for sound card fans..

No hurry, and no worries! I know the problem of not having enough time... 😉

Here is my capture of gameplay on my 286 with the latest release:

https://youtu.be/aP-Kejf5hXQ

By the way, we are all amateurs here, I guess, but to see what can be done on a 286, here is a short capture of Pinball Fantasies on my 286, with AdLib sound (PCM MOD tracker through horrid misuse of the OPL2!). All using Mode X in 240 lines, with smooth scrolling and heavy use of the video start register to display the bottom scoreboard:

https://youtu.be/piAGuDb7hL4

root42 wrote:

By the way, we are all amateurs here, I guess, but to see what can be done on a 286, here is a short capture of Pinball Fantasies on my 286, with AdLib sound (PCM MOD tracker through horrid misuse of the OPL2!). All using Mode X in 240 lines, with smooth scrolling and heavy use of the video start register to display the bottom scoreboard:

Here's a new build utilising Mode Y (320x200 planar mode, mostly so I don't need to re-design the screens). It doesn't use page flipping yet, but it does utilise additional VGA memory for storing stuff off-screen. I've mostly tried optimising the gameplay rendering, it might even run well with the "Fast" setting on 286 machines now. The intro hasn't been optimised yet and might even run slower than in previous versions due to planar mode.

Most of the speedup is done by pre-rendering the background patterns, different blocks + number graphics into VGA memory (offscreen) and then having a blitting function written in assembly (definitely room for improvement still, but rendering the "quit" screen might now be fast enough on a 286).

By using the VGA latches, and the Write Mode 0 Logical Operation OR register, I can do the "dark" shading of the background pattern as part of the blit, which is nice (I had to change the palette index layout for this to work).

At least on DOSBox, I can now turn the cycles much lower than with the previous build, of course due to memory cycles and other things, it might not be that nice on real hardware, but give it a spin.

Cool. I will probably try it out this evening.

root42 wrote:

Cool. I will probably try it out this evening.

I'll do the same. But firstly, I'll have to accompany my dad to the hospital. 🙁

root42 wrote:

Cool. I will probably try it out this evening.

Ok, here are my results:

https://youtu.be/CRS2x2qU8VI

The graphics seem much smoother now, in my opinion. The setup screen is still flickery, but that's ok. The 286 mode is not necessary anymore, apart from the intro screen maybe, which is still slow on 386 level.

I am still not sure about the sound though. How did you implement that? I think that it still does not get enough cycles. Are you using a timer interrupt to update the sound?

root42 wrote:

The graphics seem much smoother now, in my opinion. The setup screen is still flickery, but that's ok. The 286 mode is not necessary anymore, apart from the intro screen maybe, which is still slow on 386 level.

I am still not sure about the sound though. How did you implement that? I think that it still does not get enough cycles. Are you using a timer interrupt to update the sound?

Cool! I do see some artifacts with the number renderings on the right side of your screen in the video, I don't see these issues in DOSBox, maybe I'm doing something wrong there (it's the same code as the block drawing code, but maybe because I'm overlapping the 10x10 tile data (for the digits) by 2 pixels (so each digit is 8 pixels wide) causes that somehow.

About the sound, I was servicing the music playback just as part of the main loop, so any slow drawing operation would mess with it. I have now added some code to serve the music from the timer interrupt handler, in my testing in DOSBox it works now and is super smooth, but YMMV. I hope it's okay to write to MIDI/AdLib ports in the timer ISR.

New build r34 attached:

* Fix a bug that caused the block tiles to stay the same
* Music playback is served via the timer ISR, hopefully makes it smooth

By the way, I do see some corruption in the "loading" screen. Does setting the mode not clear the screen with your VGA card? Again, I might be relying on behavior of DOSBox' VGA emulation that's not the case for all hardware.

Thinking a bit more about it, the corruption we see in the loading screen might also be the corruption that's causing the digits for the score to be messed up (because those pixels aren't really touched, and I assumed they would be cleared to zero, so anything that was there previously messes up the display).

Here's an updated build that clears the VGA memory to zero when entering the graphics mode (something that seemingly I didn't need to do on DOSBox.

Hi, sorry for the delay. 🙁
I did a quick test with the different machine settings on my 10MHz 286 PC.
This time, I exchanged the OAK card with an ET4000AX.

https://youtu.be/WwTsGKRbMz4

In another test I ran Loonies 8192 on a Pentium 133 with a
Dreamblaster S1 GM synth attached to the WaveBlaster header of a SB16 (CT2230).

https://youtu.be/1JWSrZp7Q0s

I also recorded a few seconds of the music using Audacity.