Gigatron emulator for MorphOS system

[Phibrizzo]

Because i am user of MorphOS system (like Amiga OS), i did first release a Gigatron emulator for this system.
Emulator is based on source code form Appendix B form manual.
How it works can be seen here (direct link, sorry, i not have YT account):

http://blabla.ppa.pl/ftp/usr/Phibrizzo/gigaemu.mp4

On this moemt a have two problems (questions):
1. How send to Gigatron core information about key from pad or keyborad?
i mean: what is the transmission protocol?

2. I will try change size of RAM memory by change variable array from RAM[1<<15] to RAM[1<<16] but it doesn't work.
Still is 32kB. What i did wrong?

[lb3361]

1. How send to Gigatron core information about key from pad or keyboard? i mean: what is the transmission protocol?

Set variable IN to the ASCII code of the key for two screen frames, then reset it to 0xff.
https://github.com/kervinck/gigatron-ro ... temu.c#L11

2. I will try change size of RAM memory by change variable array from RAM[1<<15] to RAM[1<<16] but it doesn't work. Still is 32kB. What i did wrong?

See lines 45 and 50 in gtemu.c. Addresses are anded with 0x7fff.
https://github.com/kervinck/gigatron-ro ... temu.c#L45

[Phibrizzo]

Ad1. No mather what i put into IN variable, always work like ENTER.

Ad2. I fixed it. Now is ok.

[Phibrizzo]

Ad1. I solved the problem. Youre right i must send ASCII codes, buf for cursor keys i must send codes 0, 1, 3, 7.

[lb3361]

Ad1. I solved the problem. Youre right i must send ASCII codes, buf for cursor keys i must send codes 0, 1, 3, 7.

Cursor keys are in fact the same as the famicom arrow keys. The whole situation is in fact a bit of a mess...

• The default state is 0xff which means that nothing is happening.
• In theory, each arrow or button of the famicom controller causes one bit to go to zero. When several buttons are pressed at the same time, all the corresponding bits are set to zero.

  Code: Select all

   "buttonRight"          : 1,
   "buttonLeft"           : 2,
   "buttonDown"           : 4,
   "buttonUp"             : 8,
   "buttonStart"          : 16,
   "buttonSelect"         : 32,
   "buttonB"              : 64,
   "buttonA"              : 128,
  

• Meanwhile the PS2 interface (a.k.a. Pluggy) sends ASCII codes for most keys and also maps certain keys to famicom buttons : arrows, home, end, pgup, pgdn. There is of course some potential to confuse a combination of Famicom buttons with an ASCII code. Since all ASCII codes are below 128, this only happens when button A is depressed.
• Shortly before sending the first kits, Marcel and Walter found that many Famicom controllers behave differently with the Gigatron (*). Instead of lowering one bit per key, they work like a priority encoding, for instance returning 00000111 Instead of 11010111. These controllers cannot indicate that several buttons are pressed at once. To address the problem, they changed the decoding code in the ROM to recognize these codes and show the correct button states in variable buttonState. This also means that the ASCII codes 0x1, 0x3, 0x7, 0xf, 0x1f, 0x3f, and 0x7f, are also decoded as button presses. 0x3f is the question mark.

Practically this means that a Gigatron program must be very careful when decoding a mixture of keys and buttons. To read the keyboard, best is to use variable serialRaw because the conflicting ASCII codes never make it into buttonState. But to read the buttons, best is to use buttonState because one otherwise needs to deal with the two kinds of controllers. Note that the pluggy always sends (0xff^buttonXX). I believe that a simulator should use the originally intended codes (like the pluggy) instead of the ones that have been retrofitted to placate cheap Famicom controller clones.


p.s. --
These cheap famicom controller clones in fact behave differently in the Gigatron because the Gigatron sends them weird signals. In principle a Famicom controller wants a pulse to load the button state into a shift register, followed by a clock to shift the register into the serial connection. In the Gigatron the pulse is not a short signal, but the vsync signal which is always one and briefly zero during the vertical blank. The different behavior occur in fact because the clock (hsync) is also ticking while vsync is high. This never happens in a Famicom console. But it seems that this has an impact on a good fraction of cheap clones...

[Phibrizzo]

Thanks a lot for this all explonation.

To solve the coding problem, I did two things:
1. Wrote simple program in BASIC:

10 print peek(15)
20 goto 10

and read all needed codes. for cursors i used:
right - 254
left - 253
down - 251
up - 247

It work correctly too.

2. Added to the emulator switch for change type of signals: NES Pad/ Keyboard.

[Phibrizzo]

Now i am working on little dev system. It looks like this at the moment:




http://blabla.ppa.pl/ftp/usr/Phibrizzo/gtdev1.png
http://blabla.ppa.pl/ftp/usr/Phibrizzo/gtdev2.png

I have one question.
I would like to add gt1file handling.
How it works?