New target: Micronique Hector 1/Hector HR

[RobertK]

Thanks to Dom, we have a new target: the Micronique Hector 1 and Hector HR.

https://github.com/z88dk/z88dk/wiki/Platform---Hector

https://github.com/z88dk/z88dk/issues/2607

The Hector 1 seems like a sibling of the Bandai Supervision 8000 in terms of usability - but at least Dstar is working.

A few questions and issues:

The Hector 1:

1. In hector.cfg, why is the target constant defined as __HECTOR1 and not __HECTOR1__ ?

2. When line printing using the native console, shouldn't \n be supported?

My grtest.c sprites test only fits into memory without GenCon, and when doing this...

Code: Select all

printf("\n\n\n  Graphics Test");	
printf("\n  Screen: %dx%d",xMax+1,yMax+1);	
printf("\n\n  Press any key\n  to clear screen...\n");

...it looks like this:

Hector1_GrTest.jpg

3. I don't quite understand why getmaxx() and getmaxy() are returning 256x192 screen dimensions for the Hector 1. It's easy to override these values in our programs, but why just 256x192?

4. games.h virtual Joystick support would be nice to have. As on the VG5000, AQOP-MN instead of QAOP-MN should be used due to the AZERTY Keyboard.

The Hector HR:

5. I have not been able to get anything running yet in the DCHector emulator. I guess "Hector 2 HR+" is the model to choose, and it seems that after loading a -clib=hectorhr compiled tape, option 1 "CASSETTE" should load and run the program, just like on the Hector 1. But whatever small program I am trying to run, either with or without GenCon, nothing happens after loading is finished. Occasionally the screen briefly gets dark and then it returns to start menu again.

[dom]

I've not quite finished it, so I just merged it to get some feedback - and thank you very much for it!

Yeah, the Hector1 is really limited, I was hoping to do the Interact as well, but with the Hector being so limited and

1. I've been slowly moving over to that form to match the newlib convention - you'll see it being used in features.h for example

2. It was fairly tough to find an entry point, I'm not sure that any control codes are supported at all - I think it relied on setting up the print location outside if you wanted to do a newline - it's possibly of course that there's a better entry point available.

3. It should be the right size - the library creation was picking up the wrong files unfortunately.

4. There's actually a hardware joystick available, I'm currently working on an inkey driver so it'll get swept up into that work

5. I think the ROM entry point is incorrect for firmware printing, gencon does work, though you do have to define a font with -pragma-redirect:CRT_FONT=

[dom]

Re 5, the PUTC entry point is wrong, I'm currently trying to find it.

However Stefano, you might like this one. The HR+ ROM is being recognised as having a copy of an early Microsoft BASIC, but it's copied from ROM into RAM when it starts up.

[RobertK]

3 is fixed now, thank you.

One more issue: try compiling chessboard.c like this:

Code: Select all

zcc +hector -create-app -DMIDSIZE -o chessboard_Hector1 chessboard.c

With nightly 2024-11-07, it looked good:

Hector_Chessboard_2024-11-07.jpg

With the current nightly, it looks like this:

Hector_Chessboard_2024-11-10.jpg

[dom]

I know what the cause of that is - line clipping when one end of the line coordinates goes out of range. I'll disable clipping on line drawing for Hector1.

As a note, I couldn't get chessboard down to size where it will fit in memory without changing the org (0x4e00 seems to work btw for this example)

[dom]

Okay, so the hr library build was faulty and was using the Hector1 routines - hence it was quite broken. That's now fixed.

I've also beefed up the firmware output so it can do line feeds. However it doesn't scroll so is not overly useful apart from for quick tests.

[RobertK]

Thanks, all issues are resolved now, only virtual joystick support is still on my wish list.

I have already released H-Tron for the HR, which is indeed a very nice target system.

I'm a bit confused why the chessboard demo on the Hector 1 is working for me without changing the org but not for you. I think the tape lenght should give a rough indication whether the program will fit into memory, in the screenshots above you see that the tape counter goes up to 0005, but I could even get programs running with a length of up to 0007 (my megtaoll.c demo).

[dom]

I've now made a few changes, so I think as a target it's there:

- Inkey keyboard support - so multiple keypresses are supported
- Hardware joystick support
- The palette is remapped and an attempt made to normalise the <conio.h> colours
- A function is available for setting a custom palette

Nice work on getting HTron working so quickly - I notice that you've not got an Aquarius+ port though - any reason why not?

[Fabrizio]

Guys, thanks you for the support!

I have added support for this target in my Cross-Lib framework (which uses Z88Dk for I8080/Z80 targets).
All the 9 games I have so far written with Cross-Lib work and are playable:
https://github.com/Fabrizio-Caruso/CROS ... ctorhrplus
The only missing thing is sound I suppose.

[dom]

I think there's a buzzer, but the main sound chip is a sn76477 - I've not come across any examples (in any environment) of driving it yet though.

[RobertK]

I've now made a few changes, so I think as a target it's there:

With the current nightly, I am getting this error whatever I am trying to compile for the Hector HR:

Code: Select all

stdio/generic_console.asm:101: error: undefined symbol: __hector_reg_0x1000
  ^---- (__hector_reg_0x1000)
stdio/generic_console.asm:104: error: undefined symbol: __hector_reg_0x1800
  ^---- (__hector_reg_0x1800)

Please have a look.

[dom]

Sorry about that, I forgot to add a file and the hector was omitted from a compilation test which would have shown it. Both of those should now be rectified.

[RobertK]

Thank you, I have now released all my four programs for the HR, everything is running flawlessly.

P.S. Deepspace is out for Aquarius+ as well.

[RobertK]

I think there's a buzzer, but the main sound chip is a sn76477 - I've not come across any examples (in any environment) of driving it yet though.

I don't know if it helps, but this is from a thread on a French forum:

https://forum.system-cfg.com/viewtopic. ... 02#p260702

On Hector (all, even Hector 1) there is a SN76477 that allows you to make sounds. Its use is quite simple: 2 parameters: one allows you to choose the type of modulation:
SLF (low frequencies)
VCO (high frequencies)
Noise (white noise)
The mixer value allows you to use all or part of these sounds.
The second parameter allows you to choose capacitors and resistors (2 choices each) to modulate (a little) the sound produced.
A one-shot completes this.

For example under forth: 1 126 SOUND makes a rain sound (or a skidding car).
3 126 SOUND an alarm, etc.

Setting this up should be quite simple and would add sound to the game well, without losing FPS.


Further links:

https://forum.system-cfg.com/viewtopic. ... 06#p119106

http://randomflux.info/1bit/viewtopic.php?pid=865

[RobertK]

When I set the background colour before printing a character, cvpeek() will return 32 (Space) instead of the character's code.
Here's a comparison between the PV-2000 and the HRX:

cvpeekTest_PV2000_HectorHR.jpg

Is this a bug, or a some limitation of the Hector hardware?

I've put a test package named cvpeektest.zip here:
https://drive.google.com/drive/folders/ ... q6EqH_3zMr

[dom]

Ah. It’s a behaviour of non-attribute displays. We assume that pen0 is the background and any non-zero pen is a set pixel. So on this case it gets identified as an inverse space.

[RobertK]

Ah. It’s a behaviour of non-attribute displays. We assume that pen0 is the background and any non-zero pen is a set pixel. So on this case it gets identified as an inverse space.

Can anything be done about this problem?
The CPC and the Hector HR are affected, I had to disable BG colour on these targets in my Sokoban RK game.

On the Hector, it currently looks like this:

SokobanRK_HectorHR.jpg

But it could look like this:

SokobanRK_HectorHR_withBGColour.jpg

[dom]

I'm not sure there's a nice way around it. To get what you want you'd have to call vpeek multiple times with the foreground and background colours to check against, or something similar.

Not that I've finished writing many of my games, but I usually set things up to have a separation of ui and game logic - you can see it in dstar with the board variable so that the display can be rendered in whatever way is appropriate (for example doubled).

[RobertK]

To get what you want you'd have to call vpeek multiple times with the foreground and background colours to check against, or something similar.

You mean a workaround to change and restore the bg colour before and after vpeeking? Unfortunately that won't work, because on the affected targets there is no way to detect the "wall" character using vpeek with the bg colour set.

but I usually set things up to have a separation of ui and game logic - you can see it in dstar with the board variable so that the display can be rendered in whatever way is appropriate (for example doubled).

In my case that would be a waste of memory IMHO, because it can all be done using the on-screen characters only. Apart from that, I'm only using a "player is on a goal position" flag which saved me from having to define an extra character for that.

The bottom line is: here vpeek() is not doing what it's supposed to do...

[dom]

To get what you want you'd have to call vpeek multiple times with the foreground and background colours to check against, or something similar.

You mean a workaround to change and restore the bg colour before and after vpeeking? Unfortunately that won't work, because on the affected targets there is no way to detect the "wall" character using vpeek with the bg colour set.

Yes, that would be the change that I would make - compare against pen (bg colour) rather than pen 0. Or maybe pen (fg colour) is more appropriate.

In my case that would be a waste of memory IMHO, because it can all be done using the on-screen characters only. Apart from that, I'm only using a "player is on a goal position" flag which saved me from having to define an extra character for that

There's also a trade off between memory and performance - looking at a single byte is considerably cheaper than pulling 8/16 bytes from VRAM and comparing against the fonts. For character mapped screen there's no difference of course.

[RobertK]

Yes, that would be the change that I would make - compare against pen (bg colour) rather than pen 0. Or maybe pen (fg colour) is more appropriate.

Ok, I was mistaking this for a workaround in my game, so that would be a fix on your side, that would be nice.

[Timmy]

Yes, that would be the change that I would make - compare against pen (bg colour) rather than pen 0. Or maybe pen (fg colour) is more appropriate.

If I understand correctly, you want to change the function into checking against the current bg/fg colour instead of colour 0?

I'm not entirely convinced this is a good idea. Because this looks fine if you are making a game that's mostly monochrome, but this will get more complicated when there are more colours on screen at once.

Because that would mean you will always need to set the background colour every time you need to do a check. Which might be complicated during some point in the game.

Then again, this is about v_peek(), which doesn't need to perform well, so checking against bg_colour is likely more sensible than pen 0.

There's also a trade off between memory and performance - looking at a single byte is considerably cheaper than pulling 8/16 bytes from VRAM and comparing against the fonts. For character mapped screen there's no difference of course.

That might be true, but this is about vpeek(). Which, just like SCREEN$, is expected to grab a section of a screen and compare it to all the combinations of colours and fonts. Memory and performance is the last thing you'd want for such an operation, but rather that it would work in the worst possible screen setup.

The only thing I guess is important is that it's not imported in the final executable unless this function is used, and not be included by default.

[dom]

That might be true, but this is about vpeek(). Which, just like SCREEN$, is expected to grab a section of a screen and compare it to all the combinations of colours and fonts. Memory and performance is the last thing you'd want for such an operation, but rather that it would work in the worst possible screen setup.

We have several different types of displays:

1. Character based displays (eg +ace)
2. 1bpp with attributes (eg +zx, tms9918)
3. 2,4,8bpp packed in varying ways (+cpc, mc6847 (mode 2), +sam, +laser500, v9938)
4. RGB planes (+lynx, +pc88, +rx78)
5. Unreadable VRAM (+fp1100, general +cpm)

For 1 and 2 this problem simply doesn't exist. For 3 comparing against a single colour isn't too onerous, for 4 it's fairly verbose. For 5 we actually implement a "shadow character mapped display".

The generalised case of "auto-detecting" the background colour although desirable means that the VRAM has to be read multiple times. So in the worse case scenario (mode 8 V9938) we'd issue 8192 VRAM reads to do one vpeek. So for typical direction seeking that's 32768 VRAM reads. Which in my view would result in unacceptable performance. It's also difficult to determine the end state - is it a space or is it another character printed with colours we're not detecting on that iteration?

Of course, I may just be unaware of nice generalised algorithm so pointers welcome.