Page 7 of 7

Re: General Comments

Posted: Wed Sep 04, 2019 11:19 am
by Antoon
Thanks. I downloaded the Phoenix emulator. This seems to work on my PC and can view memory locations and execute asm code. But it seems my keyboard does not generate any input on the main Phoenix screen. (Cursor keeps happily flashing at "ready" and does nothing).

I also downloaded a copy of the project Trinity-11/kernel from GitHub. This is also fine. But when I wanted to upload my down development-branch ("ap-dev") I get an error that I have no write access to GitHub...

Antoon

Re: General Comments

Posted: Wed Sep 04, 2019 6:53 pm
by gadget
I had this problem initially (with the C++ based emulator) and it turned out that I was using the shift key, and the keyboard handler was (at least at the time) fragile and died when that happened.

Re: General Comments

Posted: Wed Sep 04, 2019 8:24 pm
by bzuidgeest
Hello Antoon,

I might be wrong but I think you misunderstood how git/github works (I'm no expert either). But you do not usually have write access to a project (unless invited by de developers). What you do is create your own so called fork. This is easy and mostly automatic. You make changes to this fork (a copy of a project in your own account). You can continually commit and sync changes to this fork. When you think you have something to share, you can create a pull request for the owner of the original repository with the changes you made. If they approve, your pull request/changes will be merged with de original repository. Quite different from how SVN would work.

Your keyboard problem is unfamiliar to me. One thing that trips people up is that the IDE start in break mode after loading the hex file. Also the IDE has break on interrupt on by default and the keyboard generates an interrupt. Better to turn that of if you want to type. Last make sure the graphic screen has focus. If not, no keyboard input will happen.

Hopes this helped you somewhat

Re: General Comments

Posted: Tue Oct 29, 2019 1:09 am
by buenos
I see on the photos that the designer used an SMSC (company) super-IO chip on the motherboard for serial/parallel ports.
The SIO functionality can be implemented on an FPGA also, I did it before. Then you would not rely on a soon to be obsolete custom chip.
What it takes is a source file I can give you, plus some IP cores from opencores.org, like the wb_lpc, the uart16550 and a ps/2 core.
What my source file does is connecting the peripherals at standard addresses, and also provides plug-and play functionality for the BIOS to discover how many ports exist in the system.

Re: General Comments

Posted: Tue Oct 29, 2019 8:31 pm
by stef
buenos wrote:
Tue Oct 29, 2019 1:09 am
I see on the photos that the designer used an SMSC (company) super-IO chip on the motherboard for serial/parallel ports.
The SIO functionality can be implemented on an FPGA also, I did it before. Then you would not rely on a soon to be obsolete custom chip.
What it takes is a source file I can give you, plus some IP cores from opencores.org, like the wb_lpc, the uart16550 and a ps/2 core.
What my source file does is connecting the peripherals at standard addresses, and also provides plug-and play functionality for the BIOS to discover how many ports exist in the system.
Buenos,

Using the SuperIO chip as opposed to use it into an FPGA was the point. The machine is supposed to replicate something from early 90s. So having less into FPGA and more outside was and still is the point.

Stefany

Re: General Comments

Posted: Wed Oct 30, 2019 12:35 pm
by frenchguy
Hi,

Continueing my investigation with C programming (which are progressing well), on the IDE until I purchase the hardware, I am searching information about how to handle mouse events and keyboard. I will even accept assembly information, LOL ;-)
Does someone have some info about that ?

Re: General Comments

Posted: Wed Oct 30, 2019 2:14 pm
by PJW
Since things are still in development, this is somewhat complicated. When all is said and done, there will be a kernel routine to get keyboard input (there is one now, although I don't think it is working at the moment). My BASIC interpreter is working with the keyboard more directly. The way the keyboard works at the lowest level is that it's an IBM PC style keyboard interface, and its registers return PC style scan codes. There is an interrupt for it that maps the the least significant interrupt flag bit for interrupt register block 1. When there is a keyboard event, an IRQ is signaled, and bit 0 of INT_PENDING_REG1 ($000141) is set. The interrupt handler on seeing that bit is set can branch off to read the scan code from KBD_INPT_BUF ($AF1060), which it then examines to determine what modifier keys are pressed (if any) and what ASCII code corresponds. The BASIC interpreter generally puts the ASCII code into a keyboard buffer, although it treats CTRL-C and carriage return as special key presses.

If you like, I can upload a ZIP file of the relevant files from the interpreter for you to look at. Unfortunately, that code does not handle the other interrupts (including the mouse). If you'd like to see more complete code, you can check out the interrupt code in the "cleaned up" branch of the kernel code: https://github.com/Trinity-11/Kernel/tr ... Cleaned-up. I believe the relevant files would be Interrupt_handler.asm, interrupt_def.asm, CMD_Parser.asm (to an extent), and keyboard_def.asm. Note that the keyboard code there is really focused around an earlier idea for how the command parser would work, and it's going to change once the Rev C board is done and we start working on integrating the existing code to the new hardware. The interrupt structure should be similar to what's in place now, but the details on what happens to the scanned code will change.

Re: General Comments

Posted: Wed Oct 30, 2019 2:15 pm
by PJW
Oh, and my apologies, but I've not done anything with the mouse. There is mouse handling code in those interrupt routines, but I've never used the mouse so I can't offer any advice there.

Re: General Comments

Posted: Wed Oct 30, 2019 4:01 pm
by frenchguy
Ok, thanks. I will have a look.