Bootstrap and boot blocks

Everything about programming, including VDP and Sound programming.
Post Reply
User avatar
Dave
Posts: 756
Joined: 11 Aug 2012 18:16
Contact:

Re: Bootstrap and boot blocks

Post by Dave » 28 Jun 2019 19:03

Minor observation with CFX-I (40 column mode), pressing <RET> repeatedly with a blank command line gives an occasional bit of corruption on the upper lines of the display (that contain just #) as they scroll. It's a sort of "ghost" effect, it just flashes a few garbage characters over 3-4 lines that disappear after they display.

(Just a guess, but they might be artefacts from the CFX Boot Screen graphic)

Not really a problem, just an observation

User avatar
Dave
Posts: 756
Joined: 11 Aug 2012 18:16
Contact:

Re: Bootstrap and boot blocks

Post by Dave » 28 Jun 2019 19:21

Martin,

for info, there some interesting stuff here, including some comments by the Bill Shen that Alan mentions, here https://groups.google.com/forum/#!topic ... m-fXksGgXY

Interestingly, the cheap STEC cards that I have shipped with most CFX's have been found to be good in his tests.
I might try and pick up a few of the others off eBay for testing.

regards
Dave

Martin A
Posts: 417
Joined: 09 Nov 2013 21:03

Re: Bootstrap and boot blocks

Post by Martin A » 28 Jun 2019 23:03

It's interesting that the CMOS/NMOS issues we've found were mentioned on that thread too. The MTX plus is CMOS as is one MTX, the other I've reverted back to NMOS for testing.

The cards I've been using are, the STEC128mb cards you sent, Kingston 4gb and Integral 2gb. No issues really with any of them.

I probably should knock up an internal ram card for the MTX so I can have a play on the real MTX here.

User avatar
Dave
Posts: 756
Joined: 11 Aug 2012 18:16
Contact:

Re: Bootstrap and boot blocks

Post by Dave » 29 Jun 2019 13:02

Hi Martin,

yes, I wonder if we should stick with the 16 bit(82C55) interface for CFX-III (if it over gets done)?

regards
Dave

EtchedPixels
Posts: 30
Joined: 07 Feb 2019 01:12

Re: Bootstrap and boot blocks

Post by EtchedPixels » 29 Jun 2019 16:05

Or put the right buffers, signal handling and delays into place ?

I actually have both designs on some of my RC2014 systems. The 82C55 one is much more reliable but a chunk slower but both of them beat doing SD by bitbanging an SD card using a Z80PIO. To be fair though I'm doing SPI mode not 4bit mode and I could probably get from 9K/sec on a 4MHz CPU to 30K/sec if I rewrote it to do that.

Same discussions going on with RC2014 as slow old CF gets harder to find and CF itself is dying out.

Anyway back on topic

I've uploaded a new version of the code. This might sort out the MTXPlus as it kicks itself into 8MHz mode, and I've also fixed one timing violation in the VDP code. I also fixed a fun bug because I hadn't realised that if you've got say 12 x 16K of RAM what you get is 16K common, 3 48K banks and a 32K bank. The probe code now avoids partial banks. I might teach Fuzix how to use those later but for now it avoids it crashing in that case.

Really the MTXplus video should probably use G5 mode and hardware accelerated render but I've yet to get that working on the MSX and I'm not sure where you put the other two VDP ports on the MTXplus ?

Alan

User avatar
Dave
Posts: 756
Joined: 11 Aug 2012 18:16
Contact:

Re: Bootstrap and boot blocks

Post by Dave » 29 Jun 2019 16:14

EtchedPixels wrote:
29 Jun 2019 16:05
Or put the right buffers, signal handling and delays into place ?

I actually have both designs on some of my RC2014 systems. The 82C55 one is much more reliable but a chunk slower but both of them beat doing SD by bitbanging an SD card using a Z80PIO. To be fair though I'm doing SPI mode not 4bit mode and I could probably get from 9K/sec on a 4MHz CPU to 30K/sec if I rewrote it to do that.

Same discussions going on with RC2014 as slow old CF gets harder to find and CF itself is dying out.

Alan
Yes, we see that the 82C55 mode is much slower and we were thinking of doing away with it on the next version of CFX, but that was before we were aware of the issues that others were having with the 8 bit CF mode.

I will take the CF issue "offline" and talk to Martin about it and what the options might be for an SD card solution going forward

regards
Dave

User avatar
Dave
Posts: 756
Joined: 11 Aug 2012 18:16
Contact:

Re: Bootstrap and boot blocks

Post by Dave » 29 Jun 2019 16:25

EtchedPixels wrote:
29 Jun 2019 16:05
Anyway back on topic

Alan
I'm pretty taken with the concept so far and wonder whether it deserves it's own section on the forum?
That probably depends on how willing you are to keep contributing going forward?
I guess that implementing FUZIX on many platforms might be more of interest to you than spending a lot of time on MTX/derivatives?
But if you're interested in a new Forum section. . . . .?
EtchedPixels wrote:
29 Jun 2019 16:05

I've uploaded a new version of the code. This might sort out the MTXPlus as it kicks itself into 8MHz mode, and I've also fixed one timing violation in the VDP code. I also fixed a fun bug because I hadn't realised that if you've got say 12 x 16K of RAM what you get is 16K common, 3 48K banks and a 32K bank. The probe code now avoids partial banks. I might teach Fuzix how to use those later but for now it avoids it crashing in that case.

Really the MTXplus video should probably use G5 mode and hardware accelerated render but I've yet to get that working on the MSX and I'm not sure where you put the other two VDP ports on the MTXplus ?

Alan
We have not used the higher ports on the 9958 for MTXPlus+ (yet)

I will download the new version

I can't run MTXPlus+ at the moment, so am testing on MTX with CFX/CFX-II

How do I get output on the second display? I can switch the keyboard input to screen 2 (VDP output), but I don't see any console output there?

regards
Dave

Martin A
Posts: 417
Joined: 09 Nov 2013 21:03

Re: Bootstrap and boot blocks

Post by Martin A » 29 Jun 2019 19:37

The MTXplus will decode the MSX VDP ports as well at the MTX ports, so if you're designing V9938/V9958 only modes you can use ports 98 to 9B. (or 01,02 9A and 9B)

The MTX plus itself has 2 different versions of CPM boot rom.
The mono version uses text 2 and software scrolls.
The colour version uses short graphic mode 6 (512x192 in 16 colours) and hardware scrolling and even with the help is somewhat slower than the mono version.

The modified MTX basic rom we use has a build time option for 40 column text 1 or 80 column text 2 (which all the recent builds use). The only graphics mod it uses is G2 like the original.

I'm going to start wiring up a memory board for my MTX shortly, so by next weekend hopefully I'll be able to test on a real MTX too.

What's the maximum number of RAM pages the software can use ??

User avatar
Dave
Posts: 756
Joined: 11 Aug 2012 18:16
Contact:

Re: Bootstrap and boot blocks

Post by Dave » 29 Jun 2019 20:01

Alan,

can you also advise what size the blocks shown in "free" for "Mem" and "Swap" are please?

regards
Dave

EtchedPixels
Posts: 30
Joined: 07 Feb 2019 01:12

Re: Bootstrap and boot blocks

Post by EtchedPixels » 29 Jun 2019 21:56

@Martin: Ok.. I need to look at text2 anyway then. For G5 and G6 you should be able to pre-expand the font into VDP memory and then just copy the rectangle you need using the VDP. Not sure if that would be faster than poking it with the CPU but for 6bit wide and arbitrary pixel alignment I'd bet it is, especially if the font is stored 8bit aligned for easy maths.

Should be able to use the full 16 lots of 48K plus common. Having said that it's not actually *that* useful unless you've got a lot you want to run at once. Stuff not being run but hanging around can end up in swap just fine.

@Dave: Mem and Swap blocks are 1Kbyte

Second display.

ed /etc/inittab
1

then hit return until you see

02:3:off:getty /dev/tty2

and do

s/off/respawn/p

then
w
q

(write, quit)

telinit q

and it should in future appear

Visual editing is on the way, but right now I don't have a termcap (control code database) entry for the propeller video so it'll only work on other screens until I figure out what to do about that. Still wondering if I should just use the kernel vt52 emulator as a front end for consistency with the other displays.

And anyway this is unix like.. whilst I have a small vi editor now (called vile for vi-like-editro) there is a reason it's called vile. I do need to write a nano-emacs or somesuch for sane people to use (me included).

Alan

Post Reply