MiSTer FPGA Forum

Posted: **Mon Jul 18, 2022 8:58 pm**

unfortunately the current development in MiSTer is using too much BRAM for many FPGAs,

I wonder why such high BRAM usage? The MCL86 CPU core uses a small number so maybe the other controllers are using up the space.

At one point I think they were using BRAM for the system DRAM up to 256KB, but now that they have SDRAM working I hope these BRAMs have been freed up for other uses. Lots of block RAM would definitely impact timing closure and increase routing time...

I dont think there is an easy way to locate the BIOS ROMs in SDRAM though. The memory range would be easy to support, however loading this RAM with the BIOS contents would take another controller and also somewhere to store the information in the first place!

Posted: **Mon Jul 18, 2022 9:11 pm**

NML32 wrote: ↑Mon Jul 18, 2022 8:52 pm
somhi wrote: ↑Mon Jul 18, 2022 7:11 pm Yesterday I was very surprised to get one of my favourite Sierra games, Manhunter New York, working very well with Tandy video & sound!! (just missed the cursors working for the game to be playable).
Yeah, the Tandy Keyboard needs some work.
I got the cursor keys to work with some Sierra games with the Tandy Bios by holding the Shift key down.

yeah Shift key plus arrows just happens to match the same keycode as a 101. There is a whole document here: http://www.oldskool.org/guides/tvdog/1kfaq.html#II.E.2

and then all the TSRs are on the oldskool ftp server, I tried a few and couldn't get them to do anything with the core + tandy bios. maybe someone else would have better success. you will need to go grab the file you see on this site directly from ftp.oldskool.org. Here are the TSRs lots of keyboard stuff: http://www.oldskool.org/guides/tvdog/utilities.html

Posted: **Tue Jul 19, 2022 1:48 am**

flynnsbit wrote: ↑Mon Jul 18, 2022 9:11 pm yeah Shift key plus arrows just happens to match the same keycode as a 101. There is a whole document here: http://www.oldskool.org/guides/tvdog/1kfaq.html#II.E.2

Well, that link has some interesting documentation about the keyboard. Specifically this bit:

The 1000SL, SL/2, TL, and TL/2 use an XT (or XT/AT switchable) keyboard with a standard 5-pin DIN connector.

Maybe these are the bioses to target in order to not get crazy with the keyboard.

Posted: **Tue Jul 19, 2022 3:03 am**

Thanks for the info.

It looks like we need a table to convert the scancode for Tandy.

Posted: **Tue Jul 19, 2022 4:32 am**

Newsdee wrote: ↑Mon Jul 18, 2022 2:25 pm
spark2k06 wrote: ↑Mon Jul 18, 2022 8:39 am @newsdee, please check the monochrome colour change in the MDA output, since the last changes it looks too dark.
Sent you a pull request with a fix for it
--
PCXT_mdafix.rbf

Thank you!

I agree with unifying the monochrome colour selection between Tandy/CGA and MDA. I have accepted your pull request, and have attached the prebeta 1.5 and prebeta 1.5 turbo versions updated with this change.

Posted: **Tue Jul 19, 2022 1:19 pm**

I added key code conversion for Tandy mode
However, I have not prepared an application that uses the cursor keys.
Could someone please try this core?

Posted: **Tue Jul 19, 2022 1:46 pm**

The changes are as follows:
https://github.com/kitune-san/PCXT_MiST ... 9441eb1343

If it works well, I will send a pull request.

Posted: **Tue Jul 19, 2022 2:03 pm**

kitune-san wrote: ↑Tue Jul 19, 2022 1:19 pm I added key code conversion for Tandy mode
However, I have not prepared an application that uses the cursor keys.
Could someone please try this core?

Arrow keys now work for me in Tandy mode.

Posted: **Tue Jul 19, 2022 2:11 pm**

kitune-san wrote: ↑Tue Jul 19, 2022 1:19 pm I added key code conversion for Tandy mode
However, I have not prepared an application that uses the cursor keys.
Could someone please try this core?

A browser called Norton Commander works now using directional keys, thanks

.

Posted: **Tue Jul 19, 2022 2:12 pm**

kitune-san wrote: ↑Tue Jul 19, 2022 1:46 pm The changes are as follows:
https://github.com/kitune-san/PCXT_MiST ... 9441eb1343

If it works well, I will send a pull request.

working perfectly. Thank you very much

Posted: **Tue Jul 19, 2022 2:21 pm**

Thank you for testing

I sent a pull request to @spark2k06.

Posted: **Tue Jul 19, 2022 2:38 pm**

MicroCoreLabs wrote: ↑Mon Jul 18, 2022 8:58 pm
unfortunately the current development in MiSTer is using too much BRAM for many FPGAs,
I wonder why such high BRAM usage? The MCL86 CPU core uses a small number so maybe the other controllers are using up the space.

At one point I think they were using BRAM for the system DRAM up to 256KB, but now that they have SDRAM working I hope these BRAMs have been freed up for other uses. Lots of block RAM would definitely impact timing closure and increase routing time...

I dont think there is an easy way to locate the BIOS ROMs in SDRAM though. The memory range would be easy to support, however loading this RAM with the BIOS contents would take another controller and also somewhere to store the information in the first place!

The core is currently using if not I'm confused 64+16 KB for BIOS, 64 kB for CGA and 32 kB for MDA, 16 kB for i8088.
For my ported cores, Demistify controller, audio, scandoubler, around 20 kB.

As far as I know most cores upload the BIOS into the SDRAM.

My target FPGA for PCXT is a CYC1000 with 76 kB (608256 bits) [66 M9k blocks]

Posted: **Tue Jul 19, 2022 3:04 pm**

I've never looked at the code, but I've always assumed that there was a general service routine on the Linux side that would do things like copying ROM files to the SDRAM. On Minimig, for instance, you can select a Kickstart to use, and it seems like the most reasonable approach would be to copy that file across immediately before launching the actual core.

Selectable ROMs in general, not just BIOS files, are omnipresent in Mister, so I'd kind of expect some copy facility from the launcher. Of course, I don't know if the Linux side has direct access to the SDRAM.

Posted: **Tue Jul 19, 2022 3:35 pm**

probably best to get IDE working before worrying about porting to other boards

(but it would be nice to get it backported to MIST one day, which has very little block RAM)

Posted: **Tue Jul 19, 2022 5:07 pm**

Newsdee wrote: ↑Tue Jul 19, 2022 3:35 pm probably best to get IDE working before worrying about porting to other boards
(but it would be nice to get it backported to MIST one day, which has very little block RAM)

Does anyone know how complex it can be to get an FPGA design from a CPLD design?

http://dangerousprototypes.com/docs/XT_ ... controller

Because this is possibly what we need, mixed to this other project:

https://opencores.org/projects/ata

Posted: **Tue Jul 19, 2022 5:12 pm**

kitune-san wrote: ↑Tue Jul 19, 2022 2:21 pm Thank you for testing
I sent a pull request to @spark2k06.

Thank you! Tomorrow I will accept the pull request and leave the two prebeta repositories updated.

Posted: **Tue Jul 19, 2022 5:23 pm**

somhi wrote: ↑Tue Jul 19, 2022 2:38 pm
The core is currently using if not I'm confused 64+16 KB for BIOS, 64 kB for CGA and 32 kB for MDA, 16 kB for i8088.
For my ported cores, Demistify controller, audio, scandoubler, around 20 kB.

As far as I know most cores upload the BIOS into the SDRAM.

My target FPGA for PCXT is a CYC1000 with 76 kB (608256 bits) [66 M9k blocks]

I correct you:

64+16Kb for BIOS, 32Kb for CGA/Tandy and 32Kb for MDA, 16Kb for i8088... And the 32Kb for MDA could be reduced to 16Kb or 8Kb or even removed, because will be used little or nothing in reality.

Of these blocks, what is feasible to move to SDRAM are the 64Kb + 16Kb of BIOS, with a little effort, I think you can use the same RAM controller developed by kitune-san, to preload there the data coming from IOCTL.

Posted: **Tue Jul 19, 2022 5:47 pm**

somhi wrote: ↑Mon Jul 18, 2022 5:57 pm Hello,

Just a crazy idea... but would it be doable to try to recreate serdrive in VHL? In that case, one would load an image from the OSD and it will be managed by the serdrive module in the core, and that module would serve the data to the XTIDE Bios.

Could be as difficult as developing an IDE/floppy controller, but maybe some developer might find it easier to handle.

Here is the source: https://www.xtideuniversalbios.org/brow ... er/library

Maybe an intermediate step, although I personally don't like it, is to bring the serdrive code temporarily into the framework (Main_MiSTer), I'll look into it.

Posted: **Tue Jul 19, 2022 6:07 pm**

@kitune-san, thank you for the improvement on the keyboard on Tandy Mode.

I have a case maybe interested you, it is on the game Grand Prix Circuit (cga mode).
If I test this game with Model: IBM PCXT, i can move the car with Numeric keypad (4 8 6 and 2) and with Arrow Keys.
With your last test build with Model: Tandy 1000, I can move the car just with Numeric keypad (4 8 6 and 2)

Thanks,

Posted: **Tue Jul 19, 2022 6:16 pm**

spark2k06 wrote: ↑Tue Jul 19, 2022 5:07 pm
Newsdee wrote: ↑Tue Jul 19, 2022 3:35 pm probably best to get IDE working before worrying about porting to other boards
(but it would be nice to get it backported to MIST one day, which has very little block RAM)
Does anyone know how complex it can be to get an FPGA design from a CPLD design?

http://dangerousprototypes.com/docs/XT_ ... controller

Because this is possibly what we need, mixed to this other project:

https://opencores.org/projects/ata

Great find! Theoretically, this should be very straightforward! Depending on how it is written, it could just work as is in some cases. https://www.edaboard.com/threads/fpga-d ... od.151970/

The logic is designed in software by drawing a schematic, and then uploaded to the CPLD. New logic circuits can be designed and tested without making new hardware each time.

I have programmed Altera chips using the above method with Quartus. How simple it is to combine with other code, I am not sure. However, manually programming the logic chips from the schematic in VHDL or Verilog should be very easy.

I have downloaded the files from here: https://code.google.com/archive/p/dange ... ads?page=1

It should be possible to get the Verilog code from the schematic. You probably need the Xilinx ISE software. https://support.xilinx.com/s/question/0 ... uage=en_US

This might be helpful to bring a Xilinx project into Quartus: http://www.pldworld.com/_altera/html/_s ... ation.html

This file linked from the above link shows examples of converted Xilinx to Quartus Verilog code in Part 4: https://d2pgu9s4sfmw1s.cloudfront.net/D ... iTblTZuQ__

Hope this helps and I can finally contribute something meaningful to this project.

Posted: **Tue Jul 19, 2022 9:10 pm**

spark2k06 wrote: ↑Tue Jul 19, 2022 5:23 pm
somhi wrote: ↑Tue Jul 19, 2022 2:38 pm Of these blocks, what is feasible to move to SDRAM are the 64Kb + 16Kb of BIOS, with a little effort, I think you can use the same RAM controller developed by kitune-san, to preload there the data coming from IOCTL.
A new sdram controller needs to be developed that manages all the callings for RAM, BIOS and VRAM and then accesses R/W the SDRAM

Posted: **Tue Jul 19, 2022 9:27 pm**

kitune-san wrote: ↑Tue Jul 19, 2022 1:19 pm I added key code conversion for Tandy mode
However, I have not prepared an application that uses the cursor keys.
Could someone please try this core?

For the Tandy mode, would it be possible to map the backslash \ key to the \ key this would come in handy for those that don't have a full-size keyboard connected to their MiSTer? On the full-size keyboards in Tandy mode, the \ key is currently mapped to the 7 key on the number pad.

Posted: **Tue Jul 19, 2022 9:43 pm**

NML32 wrote: ↑Tue Jul 19, 2022 9:27 pm
kitune-san wrote: ↑Tue Jul 19, 2022 1:19 pm I added key code conversion for Tandy mode
However, I have not prepared an application that uses the cursor keys.
Could someone please try this core?
For the Tandy mode, would it be possible to map the backslash \ key to the \ key this would come in handy for those that don't have a full-size keyboard connected to their MiSTer? On the full-size keyboards in Tandy mode, the \ key is currently mapped to the 7 key on the number pad.

Just to add to this,

Code: Select all

`, ~, |, and \

are the ones that should be added and mapped. Everything else feels good.

Posted: **Wed Jul 20, 2022 12:39 am**

I noticed that the PCXT core is not able to use filters (scanlines), it goes to a black screen when active.

I suspect it has to do.with CE_PIXEL being held at 1, although I don't fully understand how it is supposed to.be used. I see that ao486 uses it in quite a complex way.

The result of CE_PIXEL being 1 seems to be that the core horizontal resolution becomes equal to my display, e.g. 1280x200, which doesnt seem right at all.

Posted: **Wed Jul 20, 2022 1:46 am**

Is it possible to output CGA 15Khz? I think that CGA graphics card resolution is supported up to 302X200, 640X200, so it is possible to output enough on a general crt monitor or TV. APPLE II core can output 15khz. I wonder if it is possible to make the PCXT core capable of outputting 15Khz.

Posted: **Wed Jul 20, 2022 1:51 am**

suww37 wrote: ↑Wed Jul 20, 2022 1:46 am Is it possible to output CGA 15Khz?

The core is outputing 15Khz already but at the wrong resolution. It's related to the issue I talk about in my last post.
.

: 20220719_203613.jpg (324.47 KiB) Viewed 9634 times

I need to double check but I think MDA may be working better. Perhaps the issue is CE_PIXEL=1 is tied to the MDA video frequency. That could be changed (make it tied to CGA), but I do like the ability to use either MDA or CGA. Would be a shame to lose MDA, but maybe just as temporary measure until the video handling can be sorted out properly.

Posted: **Wed Jul 20, 2022 1:56 am**

Newsdee wrote: ↑Wed Jul 20, 2022 1:51 am
suww37 wrote: ↑Wed Jul 20, 2022 1:46 am Is it possible to output CGA 15Khz?
The core is outputing 15Khz already but at the wrong resolution. It's related to the issue I talk about in my last post.
.
20220719_203613.jpg

I'm glad that 15Khz is possible. The problem is resolution. I wish the developer could change the resolution to 320X200 or 640X200. Is this possible?

Posted: **Wed Jul 20, 2022 1:59 am**

suww37 wrote: ↑Wed Jul 20, 2022 1:56 am I'm glad that 15Khz is possible. The problem is resolution. I wish the developer could change the resolution to 320X200 or 640X200. Is this possible?

Its definitely possible (and I would say even required

)but I dont know how myself. It's a bit complicated and needs understanding of video pixel clocks.

Edit: my suggestion of ditching MDA might not work, because we'd still need the high res CGA outputs which may use a different clock.

Posted: **Wed Jul 20, 2022 2:12 am**

Extra horizontal scan resolution doesn't really matter much. 1280 is a multiple of both 320 and 640 and should look fine.

Posted: **Wed Jul 20, 2022 2:17 am**

dmckean wrote: ↑Wed Jul 20, 2022 2:12 am Extra horizontal scan resolution doesn't really matter much. 1280 is a multiple of both 320 and 640 and should look fine.

I tested it with a 15khz sony pvm monitor. The top part shakes a lot and breaks. 1280X200 resolution is not normally output on crt monitors or TVs that support 15khz output.

MiSTer FPGA Forum

MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT

Re: MiSTer PCXT