Discussion Forum for all things Microbee
New Model Development Updates - Printable Version

+- Discussion Forum for all things Microbee (https://microbeetechnology.com.au/forum)
+-- Forum: Microbee Forum (https://microbeetechnology.com.au/forum/forum-1.html)
+--- Forum: Microbee Hardware (https://microbeetechnology.com.au/forum/forum-6.html)
+--- Thread: New Model Development Updates (/thread-449.html)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14


RE: New Model Development Updates - someone - 18-01-2026

(17-01-2026, 11:53 PM)Matty72 Wrote: Hey Ewan, have you ever thought of introducing YCbCr color thereby increasing color count to 64 or more?

My thinking is that color ram can hold CbCr bits (4bits), while PCG ram can hold the Y bit for each pixel. A Separate PCG bank could hold another set of Y bits and the two banks alternate quickly so you perceive 2 Y bits per pixel thereby visually creating 64 possible colors. Hell, fill yet another bank with Y bits and get 128 colors (too much?).

Now you have HDMI out, you'd have to convert this 4:1:1 scheme to something a tv will accept OR create and external analog vga output board for the bee. Just something i thought might be doable at 10 and 20 Mhz that would make users happy.

There'd have to be code for it of course.

Thoughts?

Someone was lucky enough to use the HiColour RAMDACs and early VGA chips circa 1990.
Someone used a RAMDAC (or RAMLUT for digivid) but these are devices are obsolete these days.
This allows one to specify a colour index number with said device pumping out the desired output from its palette RAM.

As for output, one could use a something like a Raspberry Pi Pico2 W to act as a CGAish to HDMI screen buffer/ output upscaler as this would
allow the bee to operate and its normal speed independent of the display device (and operate without deflicker wait states).


RE: New Model Development Updates - MbeeTech - 19-01-2026

(17-01-2026, 11:53 PM)Matty72 Wrote: Hey Ewan, have you ever thought of introducing YCbCr color thereby increasing color count to 64 or more?

My thinking is that color ram can hold CbCr bits (4bits), while PCG ram can hold the Y bit for each pixel. A Separate PCG bank could hold another set of Y bits and the two banks alternate quickly so you perceive 2 Y bits per pixel thereby visually creating 64 possible colors. Hell, fill yet another bank with Y bits and get 128 colors (too much?).

Now you have HDMI out, you'd have to convert this 4:1:1 scheme to something a tv will accept OR create and external analog vga output board for the bee. Just something i thought might be doable at 10 and 20 Mhz that would make users happy.

There'd have to be code for it of course.

Thoughts?

Hey Matty.

In fact the new models can have up to 256 colours on the screen.  Normal 16 colors per pixel ( 4 bit planes ) , but then also you can choose out of 16 separate palettes of 16 colours each per character cell.
Each palette entry is 12 bits - so 4096 hues available to choose your colours from.

Video output is HDMI only, and its is scaled to 640 x 480 @ 75hz.

Here's a sample :  I updated the demo software's pictures just before Christmas for the retro meetup at Spingers Leisure centre.

                   

All of these photos are 4 bit colour with an optimised palette in windows BMP format.


RE: New Model Development Updates - VK2FVAX - 20-01-2026

Hope this doesn't sound silly .. but this is so exciting. I'm checking back numerous times a week to see if anything has changed. Can't wait to explore these systems and fiddle with code.

@Ewan: Are you taking any advanced payment yet? Even in full.

Kind Regards,
Al Boyanich

Oh.. before I forget. Will the new system have floppy drives? I use mine a lot. Also will the multi-floppy project work with it?


RE: New Model Development Updates - MbeeTech - 21-01-2026

(20-01-2026, 05:06 PM)VK2FVAX Wrote: Hope this doesn't sound silly .. but this is so exciting. I'm checking back numerous times a week to see if anything has changed. Can't wait to explore these systems and fiddle with code.

@Ewan: Are you taking any advanced payment yet? Even in full.

Kind Regards,
Al Boyanich

Oh.. before I forget. Will the new system have floppy drives? I use mine a lot. Also will the multi-floppy project work with it?

Hey Al. 

>@Ewan: Are you taking any advanced payment yet? Even in full.
No, not taking pre-payments.  No one will miss out.  These models are ongoing and designed around (with the exception of a few parts) new & available current technology parts.

>Will the new system have floppy drives?
They have floppy disk support as an option (like the Premium Plus did).

>Also will the multi-floppy project work with it?
It will, with the Floppy option fitted, but is there any point?  The new models have SDcard Floppy emulation built in so you can put the disk images on the SDcard
rather than an external gotek-like solution.


RE: New Model Development Updates - someone - 22-01-2026

Hi Ewan,
Were you able to implement an FDC using the FPGA?
Someone thinks the data separator for reading is the most complex bit because the MFM data stream frequency/jitter may vary depending upon the disk drive's rotational accuracy.
(Note: The FlashFloppy/GOTEK doesn't have this challenge since it never has to read from physical media.)

The rest should be a doddle.

Cheers


RE: New Model Development Updates - MbeeTech - 22-01-2026

(22-01-2026, 08:40 AM)someone Wrote: Hi Ewan,
Were you able to implement an FDC using the FPGA?
Someone thinks the data separator for reading is the most complex bit because the MFM data stream frequency/jitter may vary depending upon the disk drive's rotational accuracy.
(Note: The FlashFloppy/GOTEK doesn't have this challenge since it never has to read from physical media.)

The rest should be a doddle.

Cheers

G'day Someone.
It would certainly be an interesting project to implement the 2793 on the FPGA, but no, I haven't gone down that path yet.
There is a spot for the 2793 & associated parts on the PCB.  It is an option that will be able to be purchased with the kits.
I'm assuming the bulk of the kits will go out without the physical floppy option as drives and media are harder and harder to get.


RE: New Model Development Updates - Matty72 - 22-01-2026

Thanks for the response Ewan, i'm more than impressed with the new Bees coloring, 4096 hues, our eyes will love it. I know someone has mentioned sprites (other than mouse pointer), when you get round to it, it's gonna be super fun coding this machine, can't wait. Be proud buddy.


RE: New Model Development Updates - VK2FVAX - 19-02-2026

(22-01-2026, 09:29 PM)Matty72 Wrote: Thanks for the response Ewan, i'm more than impressed with the new Bees coloring, 4096 hues, our eyes will love it. I know someone has mentioned sprites (other than mouse pointer), when you get round to it, it's gonna be super fun coding this machine, can't wait. Be proud buddy.

I'm with you on that one Matty.. I can't wait to get my hands on one and start coding and exploring. 

Still checking back at least once a week to see if there's movement. Smile


RE: New Model Development Updates - benjaminboyjaminblue - 08-03-2026

Any news?


RE: New Model Development Updates - MbeeTech - 27-03-2026

Hi All.

USB mouse is now working.

I did the bulk of this work in the week before the Model Train and Hobby exhibition a couple of weeks ago, but didn't quite get it working 
in time for display then.
At that point I had confirmed that the hardware was working and had mouse packets being delivered etc.  To get the mouse working with 
Microbee Software though, I had to do some work on the Microbee CP/M Extended BIOS calls (Calls #20 Set_mouse & #21 Get_Mouse).
The updates I've done prioritise the USB mouse, so if one is connected mouse packets come from that, but if there is not one connected the
BIOS still checks for an external serial mouse (on the serial port with the mouse adapter).

I decided to spend a couple of hours on it today in between other things & found 1 bug in the BIOS updates. Easy mistake under pressure
to get it done :  ld a,(usbm_st) was written instead of  in  a,(usbm_st)  to read the mouse status port to check wither a packet is available.

It turns out that the Shell, Init & Transfer all have their own mouse routines instead of using the XBIOS calls, so at the moment, the mouse
doesn't show up when in the Shell or Init or Transfer.  I'll update them to either use the XBIOS calls or have the routines updated with the same
changes I've put into the XBIOS.

In the meantime though, the XBIOS calls have been tested with a small program that came out with the Mouse Programmers Guide and BIOS v9 
release which sets up the screen with a cross-hair cursor & allows you to set dots on the screen by pressing the left button.  Right button
click exits the program back to CP/M or the Shell: