Compukit UK101 core

[danielb]

That's how it's supposed to work (or at least, how I intended it to work). MonUK02 and Wemon only work in low resolution. When you select them, low resolution is selected for you automatically and the menu item is greyed out. When you select the other monitors, the resolution menu is reenabled.

In any case, always reset after selecting a new monitor or machine type. The machine is not usable until you do so.

D.

[EeDee]

[/quote]

I pushed a new version with fixed resolution selection.

Getting the menu right is one of the most difficult parts of the whole project. This version actually has a separate monitor menu for each machine type, but only displays one at a time, and lots of conditions for greying out of menu items.

Please let me know if there are any more bugs.

D.

That's how it's supposed to work (or at least, how I intended it to work). MonUK02 and Wemon only work in low resolution. When you select them, low resolution is selected for you automatically and the menu item is greyed out. When you select the other monitors, the resolution menu is reenabled.

In any case, always reset after selecting a new monitor or machine type. The machine is not usable until you do so.

D.

Your earlier post is clearer to me now, as well as comments in other posts.
Thanks

[danielb]

Hi all,

Here is a new test version with variable memory sizes. You can switch between 4K,8K,32K and the maximum 41K.

D.

[EeDee]

Hi all,

Here is a new test version with variable memory sizes. You can switch between 4K,8K,32K and the maximum 41K.

D.

This is great! I'm trying it now. Thank you

[danielb]

Hi all,

Here is a new test version with variable memory sizes. You can switch between 4K,8K,32K and the maximum 41K.

D.

This is great! I'm trying it now. Thank you

Could you try this version too? The first one was a little overengineered, which resulted in an unnecessarily large core. This one should behave in exactly the same way as the first.

Tks,

D.

[EeDee]

Could you try this version too? The first one was a little overengineered, which resulted in an unnecessarily large core. This one should behave in exactly the same way as the first.

Tks,

D.

Seems to be working in exactly the same way.
I've set it up to start as an unexpanded UK101. Very good!

[danielb]

Fun fact: it seems that if you tell the system at startup that it has memory of a certain size, it will believe you and not bother counting it. Therefore you can tell a 4K system that it has 8K, and all will be well until it actually tries to access memory that it doesn't have. "PRINT FRE(0)" will give wrong results based on the amount of memory that you specified.

You can test this by setting the system to 40K, and comparing how long startup takes if you specify a memory size (e.g. 41000 bytes), and if you don't.

The emulator behaves in the same way, so I assume that the real computer does too

D.

[EeDee]

Is anyone able to make the Hardware (video) section of article in the link a little clearer?
"The Superboard featured a 24 by 24 character display (yes, only 24 characters across) held in 1K memory mapped from $D000 to $D3FF. It was arranged in memory as 32*32 characters however not all are visible."
http://www.technology.niagarac.on.ca/pe ... uperboard/

[jca]

Further in the link you provided:
Although the video RAM could store 1024 characters and the actual video RAM was mapped as 32 lines of 32 characters, the actual display was 24 characters across by 24 lines – peripheral characters were not visible and used as a ‘guard band’ to prevent off-screen characters.

[EeDee]

Fun fact: it seems that if you tell the system at startup that it has memory of a certain size, it will believe you and not bother counting it. Therefore you can tell a 4K system that it has 8K, and all will be well until it actually tries to access memory that it doesn't have. "PRINT FRE(0)" will give wrong results based on the amount of memory that you specified.

You can test this by setting the system to 40K, and comparing how long startup takes if you specify a memory size (e.g. 41000 bytes), and if you don't.

The emulator behaves in the same way, so I assume that the real computer does too

D.

Oh yes!

You can go right up to 63999 before you get an error message. Always takes it's 769 bytes though.

No fun facts from me I'm afraid but noticed of WinOSI that, although it has no 24x24 setting, it boots up a 24x24 screen when using SYN600 rom, even though resolution is set at 32x32. Also the emulator skips the screen full of characters but you can just about catch it.

Daniel, just a thought but, have you tried loading RidgeCruiser with SYNMON at a 24x24 screen resolution?

[EeDee]

Further in the link you provided:
Although the video RAM could store 1024 characters and the actual video RAM was mapped as 32 lines of 32 characters, the actual display was 24 characters across by 24 lines – peripheral characters were not visible and used as a ‘guard band’ to prevent off-screen characters.

I was with you all the way up to "across by 24 lines - "

[jca]

I must say that the paper is a little short on explanations on the subject but I suppose it has to do with overscan. Imagine your screen memory as a matrix 32x32 but what is displayed is the matrix 24x24 just on the middle of the 32x32 matrix, at the periphery of this matrix you will have this "guard band" which will not be displayed on the physical screen: 4 characters on the left, 4 characters on the right, 4 characters on the top and 4 characters on the bottom.
See https://en.wikipedia.org/wiki/Overscan

[RedskullDC]

Hi jca, et al.

I must say that the paper is a little short on explanations on the subject but I suppose it has to do with overscan. Imagine your screen memory as a matrix 32x32 but what is displayed is the matrix 24x24 just on the middle of the 32x32 matrix, at the periphery of this matrix you will have this "guard band" which will not be displayed on the physical screen: 4 characters on the left, 4 characters on the right, 4 characters on the top and 4 characters on the bottom.

It's all to do with how the video signal is generated on the OSI C1p.

The Horizontal and Vertical counter circuits are always "free running".
The horizontal and vertical sync signals are *not* part of the count.

When the horizontal counter reaches it's terminal count, it bumps the vertical counter and also triggers a one-shot which generates HSYNC.
*NO* allowance is made for the back/front porch areas of the video signal, which are undisplayable.
Likewise, the vertical counter triggers another one shot which generates VSYNC, then it resets to zero.

In a nutshell, you have roughly 4 characters at each of the borders during a non-displayable part of the video signal.
32 - (4*2) = 24 displayable chars on each axis.

The display routines in the monitor/BASIC are adjusted to only show in the visible area.

Check out the bottom left corner of sheet #3 for the video generator, with the two 74LS123 one-shots.
https://osiweb.org/manuals/600revD.pdf

Hope that clarifies?

Cheers,
Red

[EeDee]

I get it now!
Thank you for the link @jca, that helped, and @RedskullDC for the OSI specific reference.

[danielb]

Hi,

I managed to get 24x24 mode working. In the version that I have at the moment, it replaces the 32x32 mode on the OSI machine, and basically only works with Cegmon, because Cegmon is the only monitor that I know how to patch to change the default screen settings.

So, is there any point to adding it to the official version? Every game is written for either 32x32 or 64x32, or 48x16 on the UK101. I can't find anything that works better in 24x24, so what would people use it for?

BTW, I run my MiSTer on a 32" monitor. 24x24 characters are comically enormous...

D.

[EeDee]

Hi,

I managed to get 24x24 mode working. In the version that I have at the moment, it replaces the 32x32 mode on the OSI machine, and basically only works with Cegmon, because Cegmon is the only monitor that I know how to patch to change the default screen settings.

So, is there any point to adding it to the official version? Every game is written for either 32x32 or 64x32, or 48x16 on the UK101. I can't find anything that works better in 24x24, so what would people use it for?

BTW, I run my MiSTer on a 32" monitor. 24x24 characters are comically enormous...

D.

Hi Daniel
There seems to be no point in 24x24 without SYNMON as that's the combination I thought might solve the RidgeCruiser screen problem (I have no longing to play it but just to see it solved). It appeared to be the combination that worked in the WinOSI emulator. Ideas/suggestions anyone?
Thanks for trying though. The current choice of settings are great.
Out of interest do you think Superboard would work with WEMON (has more features)? Watford Electronics wrote it to, but you never know

[danielb]

Out of interest do you think Superboard would work with WEMON (has more features)? Watford Electronics wrote it to, but you never know

Hi,

The Wemon that I have is set up for a UK101 at 48x16. For it to work on an OSI, it would at least need to be patched for the different screen size. I have the Wemon manual; maybe the information is in there on how to patch it.

D.

[EeDee]

Okay thanks

[danielb]

The selectable memory size is now "official". I also fixed the keyboard autorepeat rate for OSI Cegmon at high clock speeds.

D.

[EeDee]

Thanks, You're making a lovely job of this core
Anything else in mind

[danielb]

Thanks, You're making a lovely job of this core
Anything else in mind

For this version, just details. I think it's mostly finished.

Some enhancements only work with Cegmon. I recently found this repository: https://github.com/sjgray/OSI-monitor-roms, where someone has been reconstructing the source code for the various OSI ROMS. Hopefully, I will be able to find how to patch these ROMs in the same way that I patched Cegmon, so more enhancements will work with them.

Long term, I would like to add disk capability, but don't hold your breath

D.

[EeDee]

For this version, just details. I think it's mostly finished.

Some enhancements only work with Cegmon. I recently found this repository: https://github.com/sjgray/OSI-monitor-roms, where someone has been reconstructing the source code for the various OSI ROMS. Hopefully, I will be able to find how to patch these ROMs in the same way that I patched Cegmon, so more enhancements will work with them.

Long term, I would like to add disk capability, but don't hold your breath

D.

Apart from not being able to save data, except via UART , I agree it feels mostly finished. You have made a fine contribution.
To hone your newly acquired skill, maybe you'd consider attempting a port of the Nascom to Mister.
Just a thought of course

[EeDee]

Some enhancements only work with Cegmon. I recently found this repository: https://github.com/sjgray/OSI-monitor-roms, where someone has been reconstructing the source code for the various OSI ROMS. Hopefully, I will be able to find how to patch these ROMs in the same way that I patched Cegmon, so more enhancements will work with them.

I had come across that repository but due to not reading it properly didn't tie it in with what you wrote. I do that a lot
I think you have added a worthwhile core to the Mister Stable so look forward to seeing any enhancements as they come.

[EeDee]

Hi @danielb
I may be missing something but SAVE via UART appears not to be working. Tried an earlier Build and all was well

[danielb]

I'll take a look at it. I haven't tried it for a very long time.

[EeDee]

I'll take a look at it. I haven't tried it for a very long time.

Thanks
Is that how it feels?

[danielb]

I'll take a look at it. I haven't tried it for a very long time.

Thanks
Is that how it feels?

Relatively speaking...

D.

[danielb]

Here's a little progress update:

I have not been working on the core quite as intensively as before. It is quite functional and I have other stuff that needs attention.

However, I have been continuing to faff about with the video. In my latest development version, the scandoubler works properly, and I have been testing it with a VGA screen. This works, but a lot of the left hand side of the display is off the screen.

I am actually wondering if this is how it is supposed to work - Cegmon originally started lines at the 14th character, and some software, like Mon2UK, an Invaders game, and Scramble, are perfectly centered on the screen and no characters are missing.

I believe my my video code is generating the right number of pixels at the right refresh rates.

Other projects have developed specific VGA output devices to use the UK101 on VGA, like the one I used on very early versions of the core. Mine is based on Grant Searles original design. The early versions work perfectly on VGA, but look horrible because of the glitched character set.

In this case, HDMI, where you can see all of the characters, would be the exception, rather than the rule.

Does anyone happen to know how this should work?

Thanks,

D.

[EeDee]

.....

Does anyone happen to know how this should work?

Thanks,

D.

I don't, sorry @RedskullDC maybe?
I just wondered whether knowing that SAVE stopped working when multiple baud rate was added might help

[RedskullDC]

Hi Danielb, et al.

Here's a little progress update:

I have not been working on the core quite as intensively as before. It is quite functional and I have other stuff that needs attention.

However, I have been continuing to faff about with the video. In my latest development version, the scandoubler works properly, and I have been testing it with a VGA screen. This works, but a lot of the left hand side of the display is off the screen.
....

Which machine type, screen mode is causing you grief?

Current code in your repository is displaying fine for me on all modes (that I tried).
I only use the HDMI output , not the VGA port.

Cheers,
Red