![]() |
|
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) |
RE: Classic Plus Development Updates - MikeCornflake - 16-06-2024 Looks great. Good luck with finding time :-) RE: Classic Plus Development Updates - MbeeTech - 18-06-2024 Well, stuck at home with Covid, so more time on the project while I'm recovering. Corrected the scaling factor from a miscalculated factor and now the full 480 lines (vertically) are used to display the bee's 275 line output. Corrected some scheduling problems (screen / colour / attribute ram -> PCG / Font -> output serialiser timing) but a bit more to do on this, and then test with all normal screen resolutions / display modes including 'viatel' mode. RE: Classic Plus Development Updates - MbeeTech - 18-06-2024 A bit more done, and testing of various screen resolutions / modes underway. It now correctly displays the full width (was missing the left and right borders before) : Programs that use 25 character lines show perfectly (Eg Telcom & Simply Write) : and the extended graphics all looks good. I've also tried Basic, and a number of games including Robot Man and Scrambler which all look as they should. I now have to apply scaling to the hardware sprite / cursor, which I'd forgotten about (see the Bee logo in the middle of the 'Hackerman' screen - it's squashed vertically because it has no scaling.) RE: Classic Plus Development Updates - Mr Lurch - 22-06-2024 Looking great! Looks like things are getting to the pointy end. RE: Classic Plus Development Updates - MbeeTech - 27-06-2024 In preparation for the Canberra Vintage Computer Faire, the second of the 2 new models has been prototyped, and will be on display on Alan (Chickenman) Laughton's table. I've updated the demo software to show off more of the bee's display capabilities. I've also added the scaling to the hardware cursor / sprite, which now displays in the proper ratio. Here are some photos, set up in the front of the Microbee Technology Shop : I ran out of time working on the demo software to allocate the right palette to each of the pictures on the windowed demo screen, so the pictures (the Bee Logo, and pictures of the PCB, and both model shots) don't look as good as they should. The 'Hackerman' screen however uses the correct palette. All of the pictures are actually standard windows BMP files (at 4bits per pixel). The routine that loads them checks the size (in pixels) of the picture, gets the palette information and loads it to 1 of the 16 available palettes, then draws up the pixel data onto the screen. RE: Classic Plus Development Updates - MbeeTech - 11-08-2024 Not a lot to update on right now, as I've had limited time once again due to lots of assembly service work to get done. However, in the last couple of days I had a chance to update the demo software seen previously in regards to setting the correct palettes for the pictures, so a bit of software dev, proving out the hardware. Here are some photos taken today that show the pictures with the correct palettes set, and obviously a lot clearer pics as a result. The photos were taken at Springers Leisure centre in Keysborough today at the 'Vintage' section of the computer swap meet. Additionally, I've started work on updates to the FPGA / Dragonball So-Dimm. There were a number of fixups I needed to do to this board, but I also wanted to make a some changes which are : A) replace the 2Mbyte SRAM with a 48LC16M16 SDRAM which is cheaper and is 32Mbytes B) add a 1Mbyte parallel flash rom to boot from rather than rely on getting code out of the SPI flash which is used for the FPGA configuration C) once I've tested it, I want to add the HDMI & I2S sound parts. So, lots of PCB routing going on : It's a 6 layer board (1mm thick) routed with 0.125mm signal tracks, and it's very tight. More updates in the next week. RE: Classic Plus Development Updates - RetroBee - 19-08-2024 Hi Ewan, Love your work on the new machines and I see the graphics taking shape nicely! Can you elaborate more on the sound capabilities of these new machines. The only info I could find is that you are implementing "8 bit dual channel sound FIFOs"? What's this comparable to on older systems? As a comparison the NES games machine had 5 voice channels, the BBC Micro had 4 channels, while the C64 computer had 3 voices and could support 4 different types of waveforms (square, triangle, sawtooth and noise). Is the sound going to be inferior to those types of machines? And will the sound be directly tied to the CPU so everything stops or slows down while it's playing? For me as a indy-retro-game developer (and who loves the older machines) the graphics and sound are the most important things. Sprites, colours, and great 8-bit music/effects really make a system and software. Hence, why the ZX Spectrum Next is doing well I guess (among other things). I grew up with the Microbee and spent many years wanting more from the sound and graphics, I'm really hoping we can push something better on the sound possibilities. Let me know your thoughts. Many thanks, Retro RE: Classic Plus Development Updates - MbeeTech - 20-08-2024 (19-08-2024, 06:58 PM)RetroBee Wrote: Can you elaborate more on the sound capabilities of these new machines. Hey Retro. With the sound FIFO's (First in first out buffers - these store 8k of sound wave data each) you will be able to play wave files much like the Amiga / Atari ST etc. It's not CPU intensive as a chunk of sound data gets loaded in all at once, then the CPU goes off to do other things until an 'Almost empty' interrupt occurs to let the CPU know that more data is required by the FIFO's before they run out sending the sound data to the output digital to analogue converters. The 8k of sound data (per channel) gets fed (at the sound sampling rate) out to D->A converters to produce the audio. The sound voices / channels etc. that you refer to in other systems that usually use AY-3-8910 / YM2149's etc. use a different method for generating sound. I have been looking at adding a compatible core (for the 8910) into the mix as well, but I've not got there yet. The sound enhancements are probably the last on the list to tackle before release. If I don't get the 8910 compatibility into the logic design (inside the FPGA) before release, I can still do an update to include it later. RE: Classic Plus Development Updates - RetroBee - 20-08-2024 Thanks for the reply Ewan! That's awesome news on the sound front. I can't wait to get my hands on a finished system and get going on some game dev. Keep up the great work. Cheers, Retro RE: Classic Plus Development Updates - MbeeTech - 14-10-2024 Hey All. Just a minor update for now. Nothing much to show, but I have a couple of weeks to make some further progress. Working through some bugs at the moment before getting on to testing the HDMI output later in the week. * The keyboard was not working with the second processor (68sz328). I found and fixed a timing issue with the implementation of the 6545's (CRT controller) registers that was not handling the faster access times that the second processor operates at. The keyboard now works and I can now access the 'Boot manager' than runs on the second processor to let you choose which disk image to boot from, and what other images to load as further drives. Those of you with a Premium Plus or 256TC-SE will know the Boot Manager. * Added a [Q]uit option to the boot manager software so that it is not necessary to Save the boot configuration if you don't want to, and just continue with booting. * The SDcard was intermittent - sometimes it would be recognized on power up or reset, sometimes not. This was a software issue. I had earlier optimized the SDcards SPI interface routines for speed, but this caused the card responses at initialization to be intermittent. Basically the SPI clock was much faster than required (100-400Khz) for proper initialization. Once initialized the clock can then be set higher (up to 20Mhz). So I re-wrote the routines so that the SPI clock would be slower for init phase, and then use the optimized routines after that. The machine now sees the SDcard every time. * Fixed a bug in the video raster generation logic that was causing incorrect screen display which changed from build to build of the FPGA logic. A couple more bugs to look at in the screen section next. |