MSX-C — A new, low-cost MSX Turbo R computer!

Page 2/7
1 | | 3 | 4 | 5 | 6 | 7

By JEckert

Rookie (20)

JEckert's picture

07-04-2021, 02:28

st1mpy, this may realistically cost more than $100 USD, but less than $200. Compared to machines both old and new, this is meant to be among the most affordable.

By sdsnatcher73

Paragon (1662)

sdsnatcher73's picture

07-04-2021, 05:34

About the 512kB VRAM, the way you write it in the abstract it is like MSX-C would switch between V9958 and V9990. In reality both VDPs will be active at the same time and would both need access to their VRAM. So you will need a minimum of 512kB + 128kB for both VDPs to be active, you could add the extra 64kB for the V9958.

By brawaga

Resident (42)

brawaga's picture

07-04-2021, 08:52

As for my look, «C» in logo is out of font style hence you tried to preserve curvature radius from «S», presuming it is constant among the font. If so, «M», and also likely, «X» would have round shapes, but they don't. So better to have more «classic» shape to «C»: larger curvature radius and (maybe) bent endings. Now it looks too square for the whole logo look comparing to «MSX» part. As a point, please look to https://github.com/iViking/MSX-C/blob/main/README.md, where you have same in plain text. Looks pleasantly better.

By brawaga

Resident (42)

brawaga's picture

07-04-2021, 09:03

Good idea to have shared VRAM among two VDP, some interesting features it will give. But are there drawbacks? I foresee a need to arbiter VRAM accesses among these two devices.
Did you consider direct CPU access to VRAM to reduce per transaction time penalty? This thing is named «advram» in openMSX, maybe some other implementations exist too.
And, with my next suggestion we can actually run out of «cheap», but maybe not. So you are designing «Turbo» machine, and designing it from scratch. To make it more turbo, can you consider to add some DMA feature to free CPU from I/O and memory transfer routines? I will appreciate any answer, but preferrably most explained one (=

By konamiman

Paragon (1116)

konamiman's picture

07-04-2021, 11:20

Still have to read it but just a comment on the publish format: I suggest you to publish the text as a gist (https://docs.github.com/en/github/writing-on-github/creating...) in Markdown format, instead of as a .docx document. First, because that way it would be much easier to read (just open the gist in the browser), and second because it would be much easier to write comments (using the built-in mechanism GitHub has for that).

Edit: I see that you are suggesting that change suggestions should be submitted via branching/forking. Yet one more reason to use a GitHub-friendly file format.

By AxelStone

Prophet (2890)

AxelStone's picture

07-04-2021, 11:00

Very nice idea, basically "a moderm MSX" as you say. A few questions:

  • Is it a DIY project or do you plan some kind of preorder units to be sold?
  • What is the current status? Something is implemented or everything still in paper? I ask before you talk about FPGA implementations of R800 or 9990, and by the moment no implementation is available for them.

Thanks!

By SleepyCat

Supporter (1)

SleepyCat's picture

07-04-2021, 11:20

Note that Hara-san is also developing TurboR + v9990 on fpga. You can find current progress on http://hraroom.s602.xrea.com/msx/ocm/index.html

By konamiman

Paragon (1116)

konamiman's picture

07-04-2021, 12:07

Ok, I just went through the document and I must say that I love the idea, it's pretty much aligned with what I think that a new MSX machine should be.

Until there's a proper way to add comments in GitHub itself, I'll post some here:

Quote:

This should be clocked at 7.16MHz maximum, with a function to halve the clock speed for non-Turbo R software

An additional "superturbo" option where the implemented CPU works at the maximum clock speed that the underlying implementation can support would also be great.

Quote:

but only a combined 192kB (128kB + 64kB expanded) of VRAM for the V9958

You can safely leave out the expanded 64k if that helps in simplifying the implementation, that expanded VRAM is very rarely used by any MSX software if at all.

Quote:

The MSX range of memory spans from 16kB in its first iteration

This is just useless nitpicking but: the absolute minimum amount of RAM for a first generation MSX computer is 8k, not 16k.

Quote:

firmware should be subject to updates, either online or through updates in secondary storage

YES YES YES YES YES!!!

Quote:

it’s not clear whether compatibility would become an issue if memory would be expanded beyond 512kB

The RAM size can be safely raised up to 2MB. Only the 4MB expansions are problematic with some pieces of software that get confused when trying to calculate the amount of RAM pages available (since 256 doesn't fit in one byte).

Quote:

At present, the only legal implementation is a third-party BIOS, like C-BIOS

Kazuhiko Nishi told me in person that all the MSX firmware ROMs except BASIC (still owned by Microsoft) are free to use. Unfortunately I wasn't able to get a written confirmation, but if this project really moves on then it would be worth trying to contact this man again.

Quote:

A removable storage device may be omitted to lower the costs as well, and firmware updates can be distributed solely online

I strongly advocate for removable storage device to be present, even if that means removing any fixed flash storage in exchange. Do you want to store configuration, custom firmware or downloaded software? A simple SD card is perfect for that.

An USB port would be great also since with the appropriate underlying software it could allow using dongles for the missing connectivity pieces (DB9, parallel ports). And even better if the MSX itself can use the USB port ("built-in Rookie Drive"!)

Quote:

The keyboard may not consist of a numeric keypad, and keys that aren’t used by an MSX (such as page up, page down, print screen, scroll lock, or pause/break) may be removed, and the space left by removing the keys covered up by the casing

Or you can use this space to add additional control keys: force/disable boot menu, toggle CPU speed and the like.

Quote:

The most common connector for MSX gamepads have been DE-9 male, but that shouldn’t necessarily be the case today

I see value in leaving the DB9 ports in place, being able to use original game controllers is an integral part of the MSX experience. But as I said, maybe that can be implemented via USB dongles.

Quote:

To that end, the MSX-C must have Ethernet and Wi-Fi built-in to connect to the network

Yes! But please make these visible to the MSX machine, so that a TCP/IP UNAPI layer can be implemented.

Quote:

Cassettes and floppy disks are options, and players who have games in such media are likely to own an MSX that runs them

While that is true, keep in mind that most of the people owning a real MSX computer and actively using it would be very interested in getting a second (or third or fourth or...) new machine anyway, since our good old machines are, well, very old and prone to malfunction (and it's of course hard to get them repaired).

Quote:

The MSX-C will not have inputs for printers or MIDI devices

Ditto: please consider the option of adding these (at the very least DB9 and parallel) via USB.

By JEckert

Rookie (20)

JEckert's picture

07-04-2021, 15:41

I thought as much. It's not easy to make new letters out of a logo, and there's no documented font. I would certainly invite someone that can pull off a good vector design fitting your description. I'm no graphics designer. ¯\_(ツ)_/¯

By JEckert

Rookie (20)

JEckert's picture

07-04-2021, 17:38

Ok, to update, I have replaced the docx document with a markdown file
https://github.com/iViking/MSX-C/blob/main/Abstract%20for%20the%20MSX-C%20Computer.md
I am also looking for experts in hardware and software design to add as collaborators to the github distro. I personally only have a surface-level knowledge of the MSX architecture, but I know it is possible to have all the base functions of a Turbo R in a single IC. I consider that the biggest challenge, more than putting up an online marketplace.

Here's the roadmap for the project so far:
* Draft Abstract
* Abstract Feedback and Alterations [WE ARE HERE]
* Finalize Abstract
* Draft Scope
* Review and Finalize Scope
* Design Test Model
* Build, Test, and Improve Test Model
* Design Online Services/Shop
* Build, Test, and Improve Online Service/Shop Along Test
* Create Prototype
* TBD (Funding, licensing, legal stuff, management)

Ideally, I want to hand equal share of ownership of the project and it's end product and services to the community. How that is accomplished will need to be discussed and agreed upon as well. I did say this was ambitious, but I'm working as much on it as I possibly can in my free time.

Page 2/7
1 | | 3 | 4 | 5 | 6 | 7