I am trying to write a driver from scratch and I have many doubts:
I do not know how to compile only the source I am working on. I followed the instructions but cannot compile especifically the part I want, something seems to be missing.
I do not know how to add LED devices into my driver. The computer I am trying to emulate has a diagnostics port whose values are read using a LED probe add-on. Due of the complexity of the computer, it is crucial for this diagnostics port to be readable during the development.
Under Windows, how could I generate the checksum hashes for the ROMs I want to include in the project?
I do know these are very noob questions, but I am already making an effort to understand C++ and I find MAME documentation is too complex for a newcomer. If you are asking yourselves why I am going through all the trouble with this, I let you know all this hassle is for bringing the first ever emulator for this forgotten machine - so forgotten it's not even in any dump or TO-DO list.
If you don't understand C++, a MAME driver is not the ideal way to learn it, but I'll try to answer your questions.
When you add a completely new source file, the first time you compile with it you must include REGENIE=1 when doing the 'make' so that the build system will re-scan for new files. Also, don't forget to add the new driver to src/mame/mame.lst or MAME will say the driver doesn't exist when it does.
Are these individual LEDs, or a 7-segment display, or some other kind of LED display?
For hashes, a lot of people simply add fictional hashes like "12345678" the first time. When you try and run the driver, MAME will print the hashes it actually found and you can copy and paste those out from your command window.
I do understand C but C++ is not something in which I have had an excuse to deal with. I used to program web applications...
I'll take note on the REGENIE option. This will come useful indeed.
About the LEDs, any of both could be used. The diagnostics port per se expects the probe to be connected, but no probe for this machine has been found to this day. What I have is a homemade device which simply add eight LEDs. The only difference is having to interpret the outcoming signals or having them presented nicely without effort.
About the LEDs, any of both could be used. The diagnostics port per se expects the probe to be connected, but no probe for this machine has been found to this day. What I have is a homemade device which simply add eight LEDs. The only difference is having to interpret the outcoming signals or having them presented nicely without effort.
If you want to treat it as a pair of 7-segment displays for convenience, the easiest thing to do would be to have two output digits:
Code
output_finder<2> m_diag_digits;
Ensure that they're initialized in your driver_device's constructor:
To see how to display them using MAME's artwork system, refer to src/mame/layout/maxaflex.lay, and take note of the named "digit" element, and the two individual digits - "digit1" and "digit0" - that refer to it.
Give your .lay file an appropriate name and ensure it's in src/mame/layout/, and include the generated layout file as so:
Code
#include "datamaster.lh"
In the machine-configuration function, point the machine config at it:
Code
config.set_default_layout(layout_datamaster);
Build with REGENIE=1 once again, to ensure that the necessary layout-header is generated from the .lay that you created.
If you want to display each individual bit, there should be enough info above, while also referring to the maxaflex layout file, for you to intuit how to do that.
Last, but not least, it might speed up your development process by doing a single-driver build, and also using "lld" to link instead of the usual "ld". You do that like so:
Code
make SUBTARGET=myname SOURCES=src/mame/ibm/datamaster.cpp ARCHOPTS="-fuse-ld=lld" REGENIE=1
...and take the REGENIE=1 off once you've built. Re-add it if you add any new files.
Make sure that any new drivers are added to src/mame/mame.lst in the appropriate spot, and any new CPU cores or individual devices are added to the appropriate Lua scripts in scripts/src/.
Thank you very much for this information. I am, however, lost when dealing with the layout. I have updated my mame devices list and created the first commit into my private repository. You can find the new source in the following link.
The plan is to have a skeleton that runs the diagnostics steps correctly from the beginning of the work and we keep adding the required parts in the order marked by the tests. I think this way the emulator would self-verify itself.
I am sure I missed something, don't know what because I am still very green at it. Please, could anybody take a look at it?
1. Should go under `src/mame/ibm/system23.cpp` 2. `MACHINE_SKELETON` is a flag that doesn't exist in bleeding edge. 3. Needs a machine_config that describes what components your motherboard has. 4. `ROM_REGION(0x1800, "ros_unpaged", 0)` will throw a validation failure, what you map below is 0x4000 in length.
To be more explicit about point 3, do a Find In Files in src/mame/*.cpp for (machine_config &config), literally every machine has one, it's what specifies the actual hardware that existed for a machine.
1. Isn't the code already at this directory? 2. Removed the flag. 3. I don't understand this point. 4. Copy-paste issues. Corrected to 0x4000. I am examining both ibm6850.cpp and alphatpx.cpp as references.
Hm... the source is at this directory, but it's true that it is not finding it for some reason. I have the impression that is what you intended to point out, right?
It's strange. I have added the driver to mame.lst as required but it can't find it. Please, does anybody have any clues about it? Otherwise the source seems to be compiling correctly.
It's strange. I have added the driver to mame.lst as required but it can't find it. Please, does anybody have any clues about it? Otherwise the source seems to be compiling correctly.
Sorry again for the hassle
When building, you need to provide the full path to the driver file: src/mame/ibm/system23.cpp
See the function at line 124? You need a function like that in your own driver, which configures the CPU and any other devices used by the system. Let's go over the one in 600cat.cpp together -
This is the function prototype. It always takes a reference to a machine_config, called config. It's no different from a function in C, it's just namespaced to the class that it belongs to: _600cat_state.
This configures the class member "m_screen", which you can see declared on line 53. We configure it as an LCD-type screen, since this was a handheld device with a simple LCD display.
Code
SCREEN(config, m_screen, SCREEN_TYPE_LCD);
...with a (guessed) 50Hz refresh rate, a (guessed) 2500-microsecond vertical blanking interval, and a resolution of 120x36.
This sets the screen to not have vertical or horizontal blanking periods, due to being an LCD. This means that my call to "set_vblank_time" above is actually an error on my part and could potentially be removed.
Code
m_screen->set_visarea_full();
Every screen needs to have its contents painted, right? Usually, this would refer to a function in the driver class itself. But since our screen is driven by the LCD controller (see below), we point it at the appropriately-named member function provided by the LCD controller device.
This points the screen at our palette device, in order to have a more realistic-looking LCD palette.
Code
m_screen->set_palette(m_palette);
This configures the class member "m_palette", which you can see declared on line 54. palette_device is a device which, as the name implies, is used to provide a palette, for the (many) systems that didn't use direct RGB. The palette is initialized by a function in our driver class called "lcd_palette", and the palette is 3 entries long.
This configures the class member "m_lcdc", which you can see declared on line 52. It is a Hitachi HD44780 LCD controller chip. The implementation is in src/devices/video/hd44780.h (and .cpp). Since we don't know the actual clock used, we go with a relatively safe default of 270kHz.
Code
HD44780(config, m_lcdc, 270'000); // TODO: clock not measured, datasheet typical clock used
The LCD is 4 lines tall and 20 characters wide.
Code
m_lcdc->set_lcd_size(4, 20);
The HD44780 implementation uses a function delegate so that drivers using it can have exact control over how the character pixels are drawn, oriented, and so on. So we point it at our driver's function, lcd_pixel_update, which is declared at line 40 and defined starting at line 58.
This system also has a Dallas DS1643 real-time clock, so at this point in the machine configuration function, we configure the class member "m_rtc", which was declared on line 55 in our driver class declaration.
I rechecked with 600cat.cpp and understood what was I doing wrong. I committed some stupid errors, such as naming the namespace and declaring the driver inside it. I get it compiled into an application with the main menu and the only option is this driver. It is a big step for the first day. I have updated the checksums, but it just doesn't recognize them. I guess I have to tinker with it a little more.
Yesterday I managed to get the driver "working". It now gets stuck during the tests programmed in ROM. With the information I had beforehand and the result of running the program with the -debug flag I found that port A of the 8255 that manages the keyboard is used to test the CPU and the bus. It stucks just two instructions before writing to the LED display for the first time.
I took as an example the IBM Displaywriter (ibm6580.cpp), which also carries this component. At the time being I have tried by creating a private variable that holds the value of the register, then read and write to them using getters/setters and finally setting such methods as callbacks of the 8255. However, it seems that reading from the port always returns 0xff, as if nothing was assigned of that port (or tristated?). Any experience with the usage of this component?
I took as an example the IBM Displaywriter (ibm6580.cpp), which also carries this component. At the time being I have tried by creating a private variable that holds the value of the register, then read and write to them using getters/setters and finally setting such methods as callbacks of the 8255. However, it seems that reading from the port always returns 0xff, as if nothing was assigned of that port (or tristated?). Any experience with the usage of this component?
It's impossible to guess just based on a verbal description, show how you've hooked up the port callbacks. Either put the current revision on gist.github.com and post a link, or just commit what you have to your existing branch.
It's impossible to guess just based on a verbal description, show how you've hooked up the port callbacks. Either put the current revision on gist.github.com and post a link, or just commit what you have to your existing branch.
My bad. Sorry, I forgot. I will try to be more careful in the future.
At the end this was the solution that solved my problem. So the emulated Datamaster now passes the first test and assigns the LED display for the first time. It now gets stuck in the second test, but I will investigate the issue. I have seen the 7-segment LED display is directly driven by the values I send to them. Is there some sort of table/array to transform an hexadecimal number into 7-segment display code?
You will need to provide the pattern yourself. Here's an example:
(from mwsub.cpp)
That's what ended doing. Now it displays all hex digits.
By the way, now I am struggling with RIM and SIM instructions and its corresponding SID and SOD data lines. I suspect they are tied in the hardware, but in my partial schematics I did not note their state. However, judging for the code in the diagnostics area they should.
I have added the following:
int system23_state::sid_r() { return sid_sod_connection; }
By assigning a hard-coded value when reading SID, I managed to get to test four. Test three doesn't seem to exist. I guess it's time to add RAM into the machine, however it will be complicated and will require some help as it is the first time I do it.
There are four amounts of RAM obtained by five different configurations.
32KB - A single 32KB board
64KB - Two 32KB boards
64KB - A single 64KB board
96KB - A 64KB board and a 32KB one
128KB - Two 64KB boards
I know the amount of RAM can be configurable. How could I do it this way?
You can look up drivers using the ram_device, however I would get the basic driver going first and after it's working add optional features like configurable ram expansions.
The problem is how memory is structured. The system has 16KB of RAM (possibly VRAM) at 0x8000-0xbfff and then a bank of paged ram at 0xc000-0xfff. The computer expects a minimum of 32KB to start operation. The amount is detected by software with the tests.
The problem is how memory is structured. The system has 16KB of RAM (possibly VRAM) at 0x8000-0xbfff and then a bank of paged ram at 0xc000-0xfff. The computer expects a minimum of 32KB to start operation. The amount is detected by software with the tests.
That makes it much less of a problem, actually.
Map a fixed 16 kilobytes from 0x8000 to 0xbfff, then add a required_memory_bank member to your driver class, map it to 0xc000-0xffff, and in your driver class's machine_start function-override, configure the appropriate number of entries - for now, one - according to the documentation here: https://docs.mamedev.org/techspecs/memory.html#banks-memory-bank.
I will test it later today. However I think I am doing something wrong with the fixed 16kb segment too, as it seems not to be passing its part of the test.
I managed to find why test 04 was failing. In the first place, I had misconfigurated the memory. Last but not least, after all the memory tests are performed, lecture is done of port at 2eh. This input port wasn't controlled and still haven't found what it is on the board (other than port C of a 8255). The value was compared and, as it was ffh it was found to be incorrect. I applied a patch in order to make it advance to test 05 while such port is being studied.
The diagnostics routines force me to a certain order. Next one is video output and will require a 8275+8257 to achieve it, plus all the shift logic for the character representation. I imagine this may be one of the most complex parts, if I saw correctly in the other emulators. Video generation uses to be one of the most custom features each system has.
I am trying to set up the 8257 DMA for video generation, but I am having some issues when configuring it. The code is in my repo, as always; could you take a look into it, please? When it is configured and with no errors the 8275 will be added into the mix. I will require some help then to configure the screen and the video generation that writes into it.
I have also taken as a reference some terminal from microbee as it also has the 8257+8275 duet in them. I am having the following errors but no clue on how to solve them and I am stuck.
Code
ld.lld: error: undefined symbol: i8275_device::i8275_device(machine_config const&, char const*, device_t*, unsigned int)
>>> referenced by libmame_system23.a(system23.o):((anonymous namespace)::system23_state::system23(machine_config&))
ld.lld: error: undefined symbol: I8257
>>> referenced by libmame_system23.a(system23.o):(.refptr.I8257)
ld.lld: error: undefined symbol: vtable for device_finder<i8275_device, true>
>>> referenced by libmame_system23.a(system23.o):(.refptr._ZTV13device_finderI12i8275_deviceLb1EE)
ld.lld: error: undefined symbol: vtable for device_finder<i8257_device, true>
>>> referenced by libmame_system23.a(system23.o):(.refptr._ZTV13device_finderI12i8257_deviceLb1EE)
ld.lld: error: undefined symbol: i8275_device::write(unsigned int, unsigned char)
>>> referenced by libmame_system23.a(system23.o):(.refptr._ZN12i8275_device5writeEjh)
ld.lld: error: undefined symbol: i8275_device::read(unsigned int)
>>> referenced by libmame_system23.a(system23.o):(.refptr._ZN12i8275_device4readEj)
ld.lld: error: undefined symbol: i8257_device::write(unsigned int, unsigned char)
>>> referenced by libmame_system23.a(system23.o):(.refptr._ZN12i8257_device5writeEjh)
ld.lld: error: undefined symbol: i8257_device::read(unsigned int)
>>> referenced by libmame_system23.a(system23.o):(.refptr._ZN12i8257_device4readEj)
Please, could you take a look into it and tell me what I'm doing wrong (or maybe what I am not doing)? My code is at my repo at github.
I am having problems with constructing the 8275. Looking at the microbee terminal, it does not declare its 8275 as required, but instantiates it directly in the constructor. Should I do the same thing?
It depends on whether you're going to need to directly call member functions of the device in any of your read/write-handler functions or function callbacks.
What a "finder" is - required_device<T> or optional_device<T> - really is is a form of smart pointer that looks up a device in the running machine's tree of instantiated devices, and enforces type safety.
For example, if in the machine-configuration function a wd33c93_device is instantiated with the tag "scsi", and the driver class has a required_device<cpu_device> member which is provided the tag of "scsi" - remember those strings in the constructor initializers for the required devices? - then MAME will punt a validation error.
If you're not going to need to directly call member functions on the device, then it can be instantiated purely in the machine-configuration function as microb.cpp does. An instance of the device will still be created and added to the device tree with the specified tag - in microb's case, "crtc".
If it were desired, a required_device<i8275_device> m_crtc could be added to the declaration of the microb_state class, with a constructor initializer of m_crtc(*this, "crtc"), at which point this:
Unless you already know in advance that you're not going to be calling any member functions, I consider it good practice to have a finder for each device. String-based lookups at runtime can be slow, and with your overall level of experience with the codebase, you most likely are not going to be in a position of knowing in advance which functions are called once on machine construction, and which are going to be called often.
I have solved the issues with the constructor. I decided to use finders and managed to write it up in a way that it doesn't report an error for that. Still, even after REGENIE=1 I am getting the errors stated previously. Apparently it is reporting that cannot fing methods for accessing its registers? It confuses me a little.
A common workaround is to save without any mods the reported linker errors, in your case `src/devices/video/i8275.cpp` / `i8275.h` and `src/devices/machine/i8257.cpp` / `i8257.h` to force compiling those, the alternative is make clean and recompile from scratch.
Good. I have managed to get a black screen - no character is drawn yet to screen. I have looked at the source of the microbee terminal but it confuses me more than anything. I have also lost sight of the seven-segment displays. I think it is time to rearrange the layout file.
Meanwhile, could anybody with experience in the video generation explain me how to deal with it, please? Especially when it's with a 8275 or a derivative, that would be really helpful.
Thank you very much for your patience!
EDIT:
No matter what I do with the layout file, I am not getting the seven segment displays back. The layout file is at github.
I think that when you add the screen it "changes the coordinate system" to accommodate everything that is now displayed. Your width for the 7 segments are less than a pixel wide, adjust the width to something like 7 and height 10.
Thank you. I rechecked and corrected this issue. Now I have recovered the seven segment displays. Now it's time to check why it halts again. Screen is activated at test 05 but not written until test 07 so I will require them until then.
After some time examining the board I reached a via in near the CPU, but the trace was lost. Then I saw J1 between that via and another one. When tracing that second via I reached the 8085's RST5.5 pin. So the 8275 asserts RST5.5 when the jumper is bridged. Maybe I should do this during development...
By the way, what is the correct way to add a jumper?
Thank you in advance!
EDIT:
I have found that the DMA request line is the result of ANDing both the 8275 DMA Request and the DMA's channel 2 acknowledge signal. What would be the best way to handle this behaviour in the code?
Again, thank you very much.
EDIT 2:
Could it be that MAME does not support breakpoints with multi-BIOS systems? I have added an alternate BIOS and at the same time I have lost the capability to add breakpoints.
EDIT 3:
Regarding jumpers, I understand that the way most are are created is as soft jumpers, and this raises two questions. The first one, how would I create some equivalent of a hard switch in which a signal is interrumped? The second one, regarding soft switches, how could I define one that is read through a 8255 PPI?
I have found that the DMA request line is the result of ANDing both the 8275 DMA Request and the DMA's channel 2 acknowledge signal. What would be the best way to handle this behaviour in the code?
ANDing? Not ORing? I'm going to assume those signals are active low, possibly with a pull-up resistor then.
The underutilized way to handle that in MAME is with an INPUT_MERGER_ALL_HIGH() device. That lets you wire multiple outputs from other devices into the one device and its output will be the logical AND of all of the inputs. There aren't a lot of examples of it, but I use it for the I2C data line in src/mame/apple/powermacg3.cpp around line 177.
Quote
Could it be that MAME does not support breakpoints with multi-BIOS systems? I have added an alternate BIOS and at the same time I have lost the capability to add breakpoints.
MAME absolutely supports breakpoints in multi-BIOS systems. What happens when you add a breakpoint?
Quote
Regarding jumpers, I understand that the way most are are created is as soft jumpers, and this raises two questions. The first one, how would I create some equivalent of a hard switch in which a signal is interrumped? The second one, regarding soft switches, how could I define one that is read through a 8255 PPI?
Thank you in advance
Can you clarify exactly what this jumper is? Is it user-configurable, or fixed at the factory?
Yes, it's ANDed and the signals are active-low. Actually it's NOT NANDed... I will take a look into that method of yours, thank you.
By the way, I solved the issue with breakpoints. Somehow it was related with the name of the ROM region...
I have problems when accessing this site. Sometimes I am not able to access it for about a day. Is there something going on?
Again, thank you very much!
EDIT:
The jumpers selecting the language are DIP switches, while the one enabling interrupt 5.5 is an unsoldered bridge marked as J1. I don't know its state in older versions of this computer.
Wenever I try to use INPUT_PORTS_START it won't compile even if I call those ports.
I already have this line. However this does not do anything. You see, the 8275 is issued the enable interrupt command, and the interrupt flag from the CRTC is checked by the CPU using polling. It attempts it I think that 4 or 5 times, but the interrupt request flag is never asserted. I'm starting to think that this is an issue with the emulated component. If that's so, unfortunately the development of my driver will be halted until the issue is solved.
This is what I get in my log console. I imagine it should work straightforward, at least in real hardware it does... The thing is the computer just wants to detect if the CRTC is defective. In the emulated part it does not respond as it expects, so it decides it is defective and hangs.
"Enable interrupt" would be an unusual first command. Usually systems reset the CRTC and then program the screen parameters. Until valid screen parameters haven't been programmed there won't be an interrupt.
That should be what could be considered logical. However, it may not be that way. My dumps are from a machine I own, it passes all the tests and works. Maybe an undocumented behaviour of the 8275?
EDIT: Could it be a custom 8275 and come presetted?
No, there is no option to warm boot this computer. It always does its checks and initializations.
I have taken a look at the code and it really looks like an initialization of the device is done, so it doesn't seem to be a custom part fortunately. However such initialization takes place after the interrupt enable command is issued and the test is performed. So it never takes place in the emulator. This should confirm some kind of undocumented behaviour of the 8275...
If I were to test this, how should I do it? I have no more 8275 other than the one installed in the Datamaster. Maybe writing an eprom to test only that part and output the result of the status port of the 8275 into the diagnostics port?
Looking at the datasheet, it says: "HRTC and VRTC timing are random on power-up.". So it's possible that you will get an interrupt even without configuring any parameters. This isn't currently handled by the 8275 device and would need to be added (if true).
I think on making a pull request so they include this driver as-is so it gives them a way to test the 8275 behaviour that needs to be implemented. What's your opinion?
EDIT:
Already done, but I guess this process will take a lot of time. If I were to alter the device driver myself, where should I initialize the registers with dummy data so the component gets into a free-running state? It is important both to settle this and at the same time enable it to produce interrupts. The involved file is the following:
Just don't initialize it with dummy data, initialize it with something that makes a little sense. Get the values from any working driver with the same component. They're as probable as anything else, and it avoid improbable extreme cases where the system actually wouldn't have booted.
//preinitialize the device with valid data (in real hardware parameters initialize to random) m_param[REG_SCN1] = 0x4f; m_param[REG_SCN2] = 0x58; m_param[REG_SCN3] = 0x89; m_param[REG_SCN4] = 0xd9;
But I feel there is something missing...
In any case, thank you very much!
EDIT:
I had to call recompute_parameters and I got the cursor into the screen!
Thank you all the involved!
EDIT 2:
Okay. Now it halts on the same test under different circumstances. Now it is searching for a light pen? (checking the status register & 0x10). I think I have to research a bit more the board.
Sorry for the delay. For some reason the server keeps me out for some time nearly every day.
I have traced the light pen circuit. I cannot post pictures here, but I have posted it at VCFed. I still have to determine the frequency at which the latch is updated, though.
Being a noob at MAME, how would this circuitry be emulated?
Thank you in advance!
EDIT:
I placed the following code at I8275_DRAW_CHARACTER_MEMBER( system23_state::display_pixels ) at system23.cpp but it never gets asserted.
if (BIT(attrcode, GPA0) && BIT(attrcode, GPA1)) { m_crtc->lpen_w(ASSERT_LINE); //hack to test the light pen at test 05 LOG("Sytem/23: Light pen asserted\n"); } else { m_crtc->lpen_w(CLEAR_LINE); }
Then I found that apparently the 8275 driver does not support LA0 and LA1. They are defined at i8275.h but there are no mention of them at the driver itself. I guess I have to study where how they operate and then include them.
Last edited by jlopezm; 01/08/2512:52 PM. Reason: Added code
The problem is that the emulator does not trigger the strobe. I placed the trigger at the method that draws a character because that's a place where all the parameters I need are present. But maybe it's not the correct place to do so... Basically, it asserts the line always that either the actual light pen or the test circuit register a low value, and the test circuit produces a low value always that GPA0 and GPA1 are both high. In order to simplify, I left the light pen out of the equation.
By modifying your printf at char_from_buffer to printf("GG = %x\n",m_field_attr & FAC_GG) I obtain 0x0c. So both GPA0 and GPA1 should be high, right? With an attribute code equal to 0x0e it should be working, unless those bits get lost somewhere in the middle.
I cleaned the code, got rid of the palette. I also reached the part of the test where it asks for the appropriate values. However it returns zero for some reason. Still, that's been a good progress for today.
Okay. I checked again for both values and I obtained wrong column but right row. The current value for the column is very different from the expected... I will take a look into the board again in order to find what is the refresh rate of that trigger.
EDIT: Making some quick calculations, it should trigger when x=248h. The place where it triggers currently is x=220h. Any idea from where the zero could come from?
Thank you in advance!
EDIT 2:
I took a look into screen.hpos(), but I don't see anything anomalous.
EDIT 3:
I modified the 8275 to cease to import vertical and horizontal values from class screen and rely on its own counters. With that, I reached the correct row again, but also a much nearer 45h in the column value. I have a difference of 4 between this and the expected value.
Last edited by jlopezm; 01/09/2512:08 PM. Reason: correction of statement
For some reason, the DMA controller is beginning its fetching from 8209 and not 8200. It's like the first fetch is grabbing the first dma of 8 bytes and then treating that as the start point.
You can see this if you bring up the m_channel.m_address and m_channel.m_count of the 8257 in the debugger, or using a memory window to put values into the 8200 range.
So that's 9 characters of difference where it's off, and the datasheet says the light pen reading will be off by at least 3 character positions. That's pretty close to where that value should be.
Currently targeting system23 (IBM System/23 Datamaster) >wpi 0,9,w Watchpoint 1 set >g Stopped at watchpoint 1 writing 84 to 08 (PC=05BD) Stopped at watchpoint 1 writing 7F to 05 (PC=05C1) Stopped at watchpoint 1 writing 87 to 05 (PC=05C5) Stopped at watchpoint 1 writing 00 to 04 (PC=05C8) Stopped at watchpoint 1 writing 82 to 04 (PC=05CB) >g
so it's putting the 8257 into autoload, then putting 77F into the count and then 8200 into the address.
So I added 3 to the column count in the 8275 to simulate this offset and I have added a delay of a character at the System/23 source to simulate the latch. As a result I obtain 0x49, which is the expected result and as such, I passed to test 06.
just using the debugger to jam values into the 8200 range and seeing what happens:
in the debugger, just hit CTRL+M to bring up a memory window (or use the menus Debug/New memory window) and type in 8200 for the address and then start putting some values in.
********************************************************************* * * FAILURE IN CRT INTERFACE LINES <HORIZONTAL,VERTICAL, OR VIDEO). * 06 <LATCHES) * 07 ON CRT>
DISCONNECT CRT CABLE AT THE* * CPU END. RUN TEST AGAIN. IF TEST ENDS WITHOUT * ERROR CAN AUDIBLE ALARM AFTER APPROXIMATELY 30-45* *SECONDS INDICATES CORRECT ENDING), AFTER * * REMOVING THE CRT CABLE, REPLACE: 1. CRT DRIVER/ * RECEIVER CARD CSEE SM 1430). 2> CRT ASSEMBLY <SEE* *SM 1430). 3) CRT CABLE ASSEMBLIES <SEE SM 1430). * * * IF TEST FAILS AT ERROR '06' IN THE CE LATCHES, * * * WITH THE CRT CABLE REMOVED, REPLACE THE CPU * *PLANAR BOARD (SEE SM 1230). IF PROBLEM NOT *
One way to "fix" the display is to reset the DMA counters manually to 8200 and 77F. Once the counters stabilize, pause the execution in the debugger and change them manually to get the display to start at 8200.
to pass this test, you can set all the test dips and then unset them (3x) and it will pass the test. I think that this test is just to see if the various line values are changing.
Code
I8255(config, m_ppi_kbd);
m_ppi_kbd->in_pa_callback().set(FUNC(system23_state::cpu_test_register_r));
m_ppi_kbd->out_pa_callback().set(FUNC(system23_state::cpu_test_register_w));
m_ppi_kbd->in_pb_callback().set([this] () -> u8
{
return ioport("TEST06")->read();
});
PORT_START("TEST06")
PORT_DIPNAME( 0x04, 0x00, "04")
PORT_DIPSETTING( 0x00, DEF_STR( Off ))
PORT_DIPSETTING( 0x04, DEF_STR( On ))
PORT_DIPNAME( 0x08, 0x00, "08")
PORT_DIPSETTING( 0x00, DEF_STR( Off ))
PORT_DIPSETTING( 0x08, DEF_STR( On ))
PORT_DIPNAME( 0x10, 0x00, "10")
PORT_DIPSETTING( 0x00, DEF_STR( Off ))
PORT_DIPSETTING( 0x10, DEF_STR( On ))
You sure it's I8257 and not really I8275 doing the bad sorcery? A +9 would cause havoc to basically anything that uses either chips, and probably noticed in big players such as dkong.cpp or pc8801.cpp
Personally, I don't know. I haven't taken a look at the DMA yet as I am tracking traces to find the connections for test 06.
The address generation is completely the 8257 responsibility. However, the video chip used in the PC-88 is very similar to the 8275 in various aspects (I wouldn't dare to say it's a derivative of some sort, but it has similarities). As the PC-88 uses a similar tandem and has no strange effects, maybe it could be the 8275.
Currently targeting system23 (IBM System/23 Datamast >wpi 0,9,w Watchpoint 1 set >g Stopped at watchpoint 1 writing 84 to 08 (PC=05BD) Stopped at watchpoint 1 writing 7F to 05 (PC=05C1) Stopped at watchpoint 1 writing 87 to 05 (PC=05C5) Stopped at watchpoint 1 writing 00 to 04 (PC=05C8) Stopped at watchpoint 1 writing 82 to 04 (PC=05CB)
as soon as it loads the 82, you can single step and each step it will count up, it will immediately count from 8200 to 8206 in dma channel 2, Then it pauses and you can reset the counters manually and then it will work fine.
By adding more jumpers to the 2dh input port I surpassed this part, and got a nice diagnostics screen even with a trap statement.
EDIT:
I already fixed error 08. It expected the paging registers from 20h to 23h. I am sure 23h is for ROM, I am not sure about the others. I do know two are for RAM (one for CPU lectures, another for CPU reads) and another one for DMA. I will determine which of them is each one in further tests.
Now come the tests 0ah-1fh, which are meant for paged ROS ROMs. For now I have passed without the need for banks. So it will become far more difficult from now on. I don't entirely understand the docs. Do I have to create a view? If I understand correctly, I must override the read and write methods for each device that access the memory, right?
On top of that, I have the issue that while most variants of the Datamaster have 16 ROS ROMs, the oldest variants have only 14 of them. Would this be more difficult to configure?
Thank you in advance!
EDIT 2:
I'm trying with the banks, however it crashes during the tests because the input of the page exceeds the number of available pages. On top of that, I now recall that there are multiple optional ROMs that could be placed in that memory area... Is there a way to manually define the number of pages a bank has?
Actually ROS page 3 is used in most models (early units lack ROMs 10h and 11h), and page 7 is used too (18h and 19h). I debugged through tests 09h-19h to find where they do belong in the memory map. I also found that the very first byte of each ROM wxcept the boot one must equal the highmost byte of the first address they are allocated to.
I do know the paging registers, but I do not know how are they ordered in the I/O map yet (but I have them located at 20h-23h). I only know at this point that I/O port 23h is the ROM paging register, as confirmed by the tests 0a-19.
I have updated the repo with some definitions of ROMs in the paged area of the ROS. Unfortunately I don't know how to tell the bank system that I need an empty page...
EDIT:
I realized how to configure the banks. All defined ROMs in the paged area are becoming accessible to the emulated computer. I will add the remaining ones for set "R".
I tried the code you showed me but I have no way it compiles, so for the time being I commented it. I have modified it for my needs but it shouldn't be that bad...
Do you have any idea why this won't work? Please, any hint, for small it can be, will be welcome.
EDIT: Still, I haven't been able to configure the memory even after I used the proposed line at the constructor. Also, the source file has started to grow so much I am starting to consider to divide it into an h and a cpp file. What do you think about it?
Ignoring the ram device for a second, what you have in your code is a system where you have a fixed ram range from 0 to bfff and a banked range from c000 to ffff. If you do have that, you want to have that in the memory map, e.g. a ram() in 0..bfff and a bankr/w() in c000..ffff. You need to configure() the rambank in device_start then select the correct page when m_ram_*_page is updated. If you don't (which I suspect, you'd have no space for boot rom), then adapt as needed. In particular if the c000..ffff can say be ram *or* rom *or* i/o, you need a combination of bank and view, let us know.
The ram device function is to store the passed in ramsize parameter *and* give you a memory range of that size. So you have to have one, then in device_start do a m_maincpu->space(AS_PROGRAM)->install_ram(0,...., m_ram->pointer()). '...' varies depending on whether m_ram->size() can be less than 0xc000. And you also need to call configure on the bank with m_ram->pointer() and the appropriate parameters.
Please, wouldn't you know if there is any machine with a similar memory map I could take as an example? I am not very sure about the third parameter at configure_entries.
I do currently have a ram device at 0x08000-0xbfff and I am trying to configure a bankrw at 0xc000-0xffff.
EDIT: There is a complication with banks as this computer uses two different registers for the CPU to access RAM, one for reading and another for writing. EDIT 2: To add more confusion, DMA accesses memory with its own paging register, too.
Some of the TRS CoCo computers do funky stuff with banking. Whatever it was cam900 converted to a view the other week (nmk/quizdna.cpp I think) can swap banked ROM over the top of RAM.
So one bankr and one bankw at the same position on the memory map? It sounds like a clever solution to my problem.
EDIT:
Tried this solution and after fiddling a while with the I/O ports for those registers I got the first page of RAM to be detected, but not the other six. Therefore it seems to be left constrained at 32KB for the time being.
Read page being set void system23_state::ram_read_page_w(uint8_t data) { m_ram_r_page = data; m_ram_bank_r->set_entry(data & 0xf); }
Write page being set void system23_state::ram_write_page_w(uint8_t data) { m_ram_w_page = data; m_ram_bank_w->set_entry(data & 0xf); }
If you need any other code segment, please tell me.
EDIT:
I have an unrelated doubt. If I have a 8253 as a baud rate generator for a 8251, how should I express this in code? And if it directly drives a beeper, like in the PC?
I'm surprised by the +0x4000. More often than not I've seen the page 0 refer to the fixed page. You should log the ram_read_page_w/ram_write_page_w calls just to be 100% certain of what the bios looks at. Also the 16 should be m_ram->size() / 0x4000 - 1 (the -1 only if the +0x4000 is kept).
The size should remain as it is, as the datamaster also checks for page 0xf. I placed the + 0x4000 as the first 16KB of RAM are fixed and the rest are paginated.
The +0x4000 will get you memory trashing on the selection of page 16 because your RAM isn't that large. I assume you want to get rid of the +0x4000 and just set the page to 1 in your machine_reset().
EDIT: 16 * 0x4000 = 256k, so something isn't adding up here.
The system is capable of addressing up to 256KB of RAM at 0xc000-0xffff, but officially there was never a Datamaster with more than 128KB of RAM.
Memory boards contain the infamous TMS4132, which is structured in 2 separate banks of 16Kb. Nine memories per segment (8+p) so 16KB available to the CPU per bank. A 32KB board contains two memory banks and a 64KB four.
As with ROM, the computer checks them on start up and detects its presence and integrity. Then it displays this on the screen codes.
However, even if no Datamaster ever had such big amount of RAM and has no code for it on the diagnostics screen, it explicitly searches for page 0xf, probably as part of a test.
EDIT: According to the logs, all three registers are being set, so maybe implementing the DMA banking may have something to do with the issue...
I have solved the issue with RAM memory. While at first I thought it to be an issue with my configuration, I later recalled that the memory card sockets had indeed two lines each, one that determines if they are present and another one that determines if they are 64KB. I have successfully traced them on my board and reached the PPI on the same port as the A1-A4 jumpers, which were also wrongly assigned. I can choose the amount of memory by DIP switch configuration now, from 32KB to 128KB. If there is a better way to do so, please could you teach me about it?
Now it would be time to deal with the 8253 PIT. Please, how could make a speaker sound if directly connected to the output of one of the counters, like in the 5150 PC? With some luck I may be able to hear some beep! I also have to trace the outputs in order to find how does it detects that the device is installed.
EDIT: I managed to get the sound running! I had some trouble with the speaker_sound_device, but after it was resolved it went very smooth. However, I still don't know how the Datamaster expects to test the 8253, so test 34 still fails. I am thinking on starting with test 35, which is the keyboard. The Datamaster's keyboard is an intelligent peripheral and it uses a 8048 as a microcontroller. What would be the best approach to handle it?
Hello, it has been some time since the last time I wrote here. I solved all the tests and the computer made a clean IPL for the first time two days ago!
[video:youtube][/video]
Now, I have some fronts to deal with, but maybe one of the more urgent ones is regarding the keyboard, whose implementation isn't finished due to lack of data. @GoldenChild found the scancodes at 0x300 in the keyboard microcontroller ROM. Is there an easy way to get the matrix back from those processed scancodes if we have a layout with them mapped on?
Generally we just start running the microcontroller. You'll see it toggle bits in order on its GPIO pins and from there you can hook up some keys to each row/column and see what they generate.
Alternatively if there's a schematic available, that of course will show the matrix. Or since you know where the scancode table is, you can disassemble the relevant section of the microcontroller ROM and see how the rows/columns map to the scancode table.
You can actually reconstruct the matrix from the scancode table, according to the ibm manuals there are 88 possible keys, and there's 83 that are used, 00 goes in the table where there's a gap.
If you look at hi-res pictures of the 5322 or 5324 keyboards, you can see the matrix connecting to the pads. Also you can figure out how it's connected from the pictures of the board traces.
I think I've got a pretty good idea of how it works, there's 11 matrix lines and an 8273565 sense amplifier (that has a multiplexer which selects which of 8 lines to sample) (11 matrix lines * 8 sense lines)
(from my posting on reddit:)
Also, I found some disassemblies of various IBM keyboard controllers, some of which also use the same capacitive sense amplifier, the 9314 (aka the 8273565)
with the scancode table order drawn on top, 11 matrix lines (going from right side to left), following the sequence from the bottom to the top are the sense lines (8)
(there's one scancode in the table that isn't shown (5a) so I don't know what's up with that one)
Thank you for the information. I was aware of the computer interface pins because I had to solve the test 35h and for this reason communication between both microprocessors had to be done. Examining diagrams for the 5150 and the 5160, I can say the microcontroller was used in a completely different way. The parallel data bus from the microcontroller is used as interface with the computer in the Datamaster while in the PC it drives the matrix, apparently.
The Datamaster is capable to recognize when the keyboard lid is open. So maybe the 5ah scancode may be from a hidden button.
I have some errands to do this morning, but when I get home again I will check again. What I still don't understand is the usage of the sense amplifier... it seems to have four data line as input, however the output of the matrix is eight bits wide, right?
it has a multiplexer built in, so it uses 3 bits to select one of the sense inputs, the 3 bits can choose 1 of 8 possibilities (from 0 to 7). They had to do this because there just aren't enough i/o pins on the 8048 to drive 11 bits of matrix and 8 bits of inputs along with 7 bits of output.
The microcontroller is just wired up slightly differently than the IBM XT, they're using the bus to drive serial data to the computer in the XT instead of parallel data here in the Datamaster, but otherwise very similar.
with regards to the hidden button, there's what looks like a capacitive pad near the microcontroller, (in the upper right of the board), maybe that is where that's coming from
A little experiment to generate the PORT from the scancode table with lua
Code
a = io.open("KBD_8048.bin","r")
b = a:read("*all")
for i=0x300,0x300+11*8-1 do io.write(string.format("%02x ",b:byte(i+1))) if (i+1)%8==0 then print() end end
function hex(a) return string.format("%02x",a) end
function domatline(line) print('PORT_START("MD'..string.format("%02d",line)..'")') for i=0,7 do c=b:byte(line*8+i+0x300+1) cstr=hex(c)
if c~=0 then print("PORT_BIT( 0x"..hex(2^i)..", IP_ACTIVE_LOW, IPT_KEYBOARD ) PORT_CODE(KEYCODE_) PORT_CHAR('') PORT_CHAR('') // ".."scancode "..cstr)
else print("PORT_BIT( 0x"..hex(2^i)..", IP_ACTIVE_LOW, IPT_UNUSED ) // ".."scancode "..cstr) end end print() end
for matline = 0,10 do domatline(matline) end
calling the matrix drive lines MDxx as in src/devices/bus/pc_kbd/pcxt83.cpp
My current problem is that being capacitive, the sets and resets the column scan values, so they are a strobe instead of a more constant value. By the time the key value is read, the counter is always 0. I will update my repo soon.
As far as I went, the counter is reset before I can actually use it. I have tried to "latch" it, but I can't get it to another value other than 0. Same happens with the three selection bits, they change but by when T1 is read they are reset to their default at 7...
As far as I went, the counter is reset before I can actually use it. I have tried to "latch" it, but I can't get it to another value other than 0. Same happens with the three selection bits, they change but by when T1 is read they are reset to their default at 7...
Then latch it from the other direction. Look into PORT_CHANGED_MEMBER.
Assuming a similarity to the PC/XT (commented disassembly at https://github.com/Halicery/8042/blob/main/8048_XT_INTERN.TEXT) the microcontroller tells the external circuitry when to latch the bits. On the PC/XT there are 2 latches, Q (latches the selection bits) and RESET (latches the value read from the keyboard matrix).
This is typical late 70s/early 80s IBM overengineering. Most keyboard microcontrollers do what you'd expect: set the selection bits and read live.
I have been able to stabilise the values of the counter and the select signals until T1 is read. I can see them changing through the logs.
The next step is to assign the real key to the emulated one. I have been trying to assign "Reset Error" (6e) to F5 as it is the position it has in the original keyboard ("Reset error" became F5 in the transition from the Datamaster to the IBM PC) but I haven't got any reaction to the key being pressed. What would be the best way to test this?
Are those inputs read as active low or active high? Wrong input pressed polarity can cause a stuck case where the host CPU believes everything is pressed and do nothing (or at best cause havoc).
It's somewhat common for microcontrollers to not properly detect stuck keys if that's the initial state. But add some printf()s or whatever and see if the T1 read callback is returning what you expect it to.
I have successfully read keys, but the scancodes don't seem to match... I imagine I have to revise the matrix again.
EDIT: By the way, I would like to assign the unassigned ROM space to a known value (for example 0xff). What would be the best way to so? With uninitialized memory I get some sporadic ROM errors between tests 1A and 29...
EDIT: By the way, I would like to assign the unassigned ROM space to a known value (for example 0xff). What would be the best way to so? With uninitialized memory I get some sporadic ROM errors between tests 1A and 29...
Replace
Code
ROM_REGION(0x24000, "maincpu", 0)
with
Code
ROM_REGION(0x24000, "maincpu", ROMREGION_ERASEFF)
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
This time I think I do require some revision by someone else. I have to revise the keyboard matrix again, but there's something that is troubling me: the scancodes generated do not match the characters I get to the screen. There's a catch, that is the verification scan codes are working fine, but when it comes to the regular ones, I even get some keys with multiple key codes...
For those of you who have cloned jlopezm's github and are following along, to get past the startup tests you need to unset all the DIP switches except for the ones that deal with memory.
It's great to see some keystrokes working.
I haven't got time today but I'll try to figure out why the matrix isn't what we expect. (Hopefully it will stop snowing here...)
I have some more issues with the keyboard. All the space for the keys has been used, but even so, a lot of keys are missing. I have seen a lot of invalid scan codes and even combinations trigggered by a single key stroke. Maybe my keyboard is different from the one pictured here in this thread, it could be that my unit has an entirely different matrix... as the computer always receives the scancodes it really does not care about the matrix. There's also the possibility that there could be more columns, but so far I have been unable to find them. It may also be that my logic for the keyboard could be entirely wrong.
I have made tests on that machine that could give goosebumps to other owners of the system. But our red line lies within the keyboard. Fortunately, with the help and contributions of @Golden Child and another Datamaster owner I have had all the information required to reach the stage I'm at with the keyboard.
There are other things to do in this emulation that only me or any other Datamaster owner can do:
Paging the character ROM.
Setting the DMA page.
Build the Datamaster bus (there are undocumented signals).
Build the Datamaster keyboard bus (for internationalization -> our small community has people around the world: USA, Canada, Spain, Andorra, France, Belgium, Italy, Deutschland, Romania, and maybe others still not contacted); it also has undocumented stuff...
Dump the FDC microcontroller and study the card.
Document the drivers.
Add remaining jumpers
Dump and document ROMs
Add the printer port
There are issues that could be resolved by someone more experienced than me in MAME:
Fix the uninstalled ROMs errors (sometimes in the space of uninstalled ROMs the program finds the signature for a present ROM and checks it, but as there is only garbage it does not pass the test). This happens at 10, 11, 1A-29.
Fix a crash at test 19. Cause is unknown.
Replace parts of my poorly produced code with something more worthy of MAME standards. While having been programming for some years, I am still a novice in C/C++ and MAME.
And finally we have the keyboard, whose communication has been found but the expertise of someone with knowledge of MCS-48 may be the only way to make it viable.
I have also some doubts regarding the definitions of dip switches. So far I have made them as in the hardware, but would it be better to do it with only the valid options (for example in the language switches)?
With the virtual machine in the current state, I will center myself on tasks of the first group. Basically because only owners of a unit can do them. At the same time, I would like to consolidate the learnt knowledge by building a hardware clone of the computer. I would be very grateful if someone could help me with stability/quality issues and if someone with experience with such microcontroller could join, please. I am not asking people to write it for me, as you have seen I have done it by myself (with lots of help, of course). From March on I will have less time to dedicate to the emulator, and from September on, I will not have regular access to the System/23 computer except during special occasions. My goal would be to deliver a working machine before I lose access to the hardware, but I cannot do it alone. Due to the nature of the hardware, reverse-engineering is a more costly process than usual.
Please, could I count with some collaborators? I hope I am not asking too much, and if I do I ask your forgiveness. In any case, wether if you accept or refuse, thank you very much. If I had been alone this wouldn't have progressed as much as it has done.
You can submit the current work-in-progress and get it into MAME (or send it to someone who can make it acceptable for inclusion) then it will be more accessible to others who may step up and try to fix things. Of course if you have not finished then finish your work first. But do get it into MAME at some point even if not fully working otherwise your work will have been for nothing.
I wonder if that the bit reversal in read_keyboard may be unnecessary. In the documents, it says that the bits are reversed coming out of the keyboard controller bus, but when the I8255 reads them on port A maybe it is hooked up in reverse too, so the net effect is that the bits aren't reversed when they're actually read.
If we take out that reversal bitswap, the matrix looks more like what we would expect to see from the table in rom at 0x300.
For the time being I am testing it without the reversal and the matrix seems correct, at least for the unshifted characters. When shift is pressed, I get the wrong character on screen again; however that's something I have to investigate later on. For the Pull Request, there would be the reversal in the keyboard and also in the computer to compensate and also to be respecting the pinout in the service manual of the computer. Thank you!
Here's a fragment of code that helped me experiment with the key matrix. You press 0-9,a to select the matrix drive line, and keypad0 to 7 to select the sense line. Pressing the sense line presses the key for that combination of matrix drive line and sense line.
I have good news. I have completed assigning keys to the keyboard. BASIC works! I am updating the repo so anybody interested can see the code and play with BASIC. Thank you!
I write again because I am currently repairing the Datamaster of a colleague and he has a different romset than mine, so I would like to make it known that I will be adding it when the ROMs are dumped. I think I have other romsets too, so I'll be complimenting the work with them, too.
Having received a second keyboard and a second floppy controller during this process makes it possible to add a second floppy controller code and opens the possibility to dump the floppy disk microcontroller code too.
I managed to repair the computer enough for it to display the diagnostics codes, but it gets stuck at test 05h (8275 + 8257). Therefore, I have an important conclusion that will affect the emulation at its core. I have detected a difference in the behaviour of the stock 8275 respect the Datamaster's one respect the interrupts. This means I will have to roll back some of the changes I made in the 8275 device. At the same time, I will have to add another one with the expected behaviour of the Datamaster's CRTC. As I haven't created a variant device yet, do you know if it is hard to do?
EDIT: Another Datamaster will be coming my way soon, so I will be able to add even more features. This one will be mine, unlike the one I am currently repairing.
EDIT 2: I am having to patch ROS 02h to rewrite test 05 for compatibility with the stock devices. Could I ask for some help to do so?
EDIT 3: I have corrected the 8275 device, added the IBM CRTC, and created a second machine with the stock 8275.
This is to clarify and correct a few statements I made in the last post. A Datamaster set of boards arrived yesterday from USA. The computer mostly works, or at least is working more than the French Datamaster I am repairing. I have been able to conduct some tests on the American unit. Apparently my claims that the IBM CRTC is different from the stock 8275 is wrong. The American motherboard accepted the stock 8275 and even the Soviet KR580VG75. This means that I will have to roll back the latest changes and restore the previous values. This means that there is no value for the second emulated machine I made, other than for testing purposes with a 8276, but even that could be made with a single emulated machine running a virtual 8275.
I have news that could expand the development of this emulated machine further.
In the first place, I was able to test a French keyboard on my Spanish model and found that the keycodes remain the same, their translation depends exclusively of the configuration switches of the computer.
Also, the microcontroller at the disk drive controller card has been successfully identified as 8048 and dumped. Maybe it is time to start studying the card.
A package of dumps will be archived during what remains of this week and therefore will contain the first full set of a Datamaster ever dumped (my last version lacked the floppy controller). It will also contain different versions of the firmware. This will be the largest package of Datamaster firmware to be released to this date.
In a few weeks I may receive a package of leased boards to dump and study. I don't own these boards, therefore it will bring in new data to my research and more expansions to the machine.
In light of these new developments, I may be able not only to continue the development of my current machine, but to force it to implement interfaces such as the expansion bus.
I am thinking about the word-processing card, and it will be a challenge for me. In the first place, it is an optional device, so it will require the pre-ISA bus to be defined. In the second place, it contains a second 8275 CRTC so it means it will generate a "second screen". Finally, that it intercepts the video signal of the motherboard and possibly disables it to supplant it with the second field generated by the auxiliary CRTC. I know there will be some time before this piece of hardware reaches me, but I would like to have some idea of how to treat it when it arrives. Please, could anybody give me some piece of advice or guides on how to proceed with the foresaid stuff?
The biggest lift there is going to be just defining and attaching the bus. Does this card completely replace the motherboard's video or overlay it? Taking completely over a system's built-in video from a bus card is very doable, I just did it in 0.277.
I still don't know, the part still has to arrive. Still, considering it has an independent clock from the motherboard I don't think it overlays, but replaces it.
Yesterday I found I/O ports for the NEC 765 and a 8255 in the Floppy disk controller card. How would I have to do to define the bus, please? This way I could start with the development of the FDC card.
![[Linked Image from i.imgur.com]](https://i.imgur.com/pAyNW2u.png)
![[Linked Image from i.imgur.com]](https://i.imgur.com/hTWNyTq.png)
![[Linked Image from i.imgur.com]](https://i.imgur.com/IIWbebE.jpeg)
![[Linked Image from i.imgur.com]](https://i.imgur.com/MwONHJV.jpeg)
![[Linked Image from i.imgur.com]](https://i.imgur.com/CbLQsMQ.jpeg)
![[Linked Image from i.imgur.com]](https://i.imgur.com/QN0NcIq.png)
![[Linked Image from i.imgur.com]](https://i.imgur.com/KfzCwy9.png)
