Pi-based Co-Pro on the cheap - 100MHz 6502 for £10? (now over 400MHz)

[hoglet]

hdmi_mode=31
hdmi_mode=19

Those are both as expected (same as on my setup), and both are different to your original screenshot.

So whatever resolution was picked by default was different to both of those.

I'm not too concerned, in cases like this we can always do what you have done, and manually force a sensible resolution.

Dave

[sydney]

Thanks for the help with the monitor. I've decided to go with two monitors in the end as the monitor I designated for use with the pi is really nice over hdmi.
I've spotted another issue, I hope it's OK to report here if not I'll try reporting any other issues on github.
I'm currently messing about with BBC Basic and Tom Seddon's update of Acornsoft BASIC Editor.
When using the pi frame buffer on the 65C02 processor scrolling up through the program no longer works other than for the top line.
Pressing F2 to return to the top of the program works but if you scroll down and try to scroll back up only the top line updates.
This works fine without the pi frame buffer in use.

https://photos.app.goo.gl/BxQF2cVP2rmXHeRq6
https://photos.app.goo.gl/S4MDenB4apj7SEXx9

[hoglet]

I've spotted another issue, I hope it's OK to report here if not I'll try reporting any other issues on github.

Here is fine.

I'm currently messing about with BBC Basic and Tom Seddon's update of Acornsoft BASIC Editor.
When using the pi frame buffer on the 65C02 processor scrolling up through the program no longer works other than for the top line.
Pressing F2 to return to the top of the program works but if you scroll down and try to scroll back up only the top line updates.
This works fine without the pi frame buffer in use.

There are certain limitations to the 256-byte VDU driver that's squeezed into some free memory at &2C0-3FF on the 6502 Co Pro.

Currently the 6502 VDU driver doesn't currently override the following VDU related MOS API calls:
- OSBYTE &09 (Set flash mark time)
- OSBYTE &0A (Set flash space time)
- OSBYTE &13 (Wait for VSYNC)
- OSBYTE &86 (Read text cursor position - POS and VPOS)
- OSBYTE &87 (Read character at text cursor position)
- OSBYTE &A0 (Read VDU variable)
- OSWORD &09 (Read pixel value)

So when these are called, the return values reflect the host display rather than the Pi display.

Of these, its most likely OSBYTE &86/87 that are causing problems with the editor. I'll try to confirm that tomorrow. It's also possible this is something else entirely.

(The lack of these calls also break the Master Welcome Disk Menu)

Implementing these is not difficult, but it will make the VDU driver grow, and we might need to look at putting it elsewhere.

But I think you have prompted me to have a go at this tomorrow (I need a break from BeebFPGA!)

Dave

[hoglet]

Of these, its most likely OSBYTE &86/87 that are causing problems with the editor. I'll try to confirm that tomorrow. It's also possible this is something else entirely.

I checked the source, and it is using OSBYTE &86 and &87.

It is also using OSBYTE &A0 to read certain VDU variables:
- text window coordinates
- current screen mode

But as well as missing these, it's using VDU 11 to scroll the screen downwards, which is definitely a bug that needs fixing.

I'll try to spend some time on this tomorrow.

Not sure where I'll put a large VDU driver though.

Are you using high versions of the BASIC Editor and/or BASIC?

Dave

[sydney]

Thanks Dave.
I'm not sure if I'm using the high version of the Basic Editor which probably means I'm not. The particular program I'm writing at the moment targets ARMBASIC to run on the native arm processor. I write using the fast 65C02 and the Basic editor, save, exit, switch to the native arm, launch ARMBASIC, load and run, find a bug and switch back. It sounds worse than it is!

[hoglet]

The particular program I'm writing at the moment targets ARMBASIC to run on the native arm processor. I write using the fast 65C02 and the Basic editor, save, exit, switch to the native arm, launch ARMBASIC, load and run, find a bug and switch back. It sounds worse than it is!

If it works for you, that's all that matters.

I spent some time on this yesterday and was able to add:
- OSBYTE &86
- OSBYTE &87
- OSBYTE &A0
- Scrolling the screen downwards

https://github.com/hoglet67/PiTubeDirec ... ognose-dev

With these in place I can run Tom's Acornsoft Basic Editor (v1.45).

I need to do a bit of tidying up, then I'll post another release candidate (probably Wednesday).

Dave

[hoglet]

Thanks Dave.
I'm not sure if I'm using the high version of the Basic Editor which probably means I'm not. The particular program I'm writing at the moment targets ARMBASIC to run on the native arm processor. I write using the fast 65C02 and the Basic editor, save, exit, switch to the native arm, launch ARMBASIC, load and run, find a bug and switch back. It sounds worse than it is!

Sorry this got delayed a few days....

Here's a new release (Hognose-rc5) that should stand a better chance of working with Basic Editor on the 6502 Co Pro:
https://github.com/hoglet67/PiTubeDirec ... ognose-rc5

Let me know how you get on....

Dave

[tom_seddon]

Does this setup let you have more than 32 rows on screen? No promises the editor can handle more than that... but take that with a pinch of salt. The display routines have always Just Worked, so I haven't had to delve too deeply into them.

--Tom

[hoglet]

Does this setup let you have more than 32 rows on screen?

Yes, it does.

Pretty much every RISC OS screen mode is supported:
https://www.riscosopen.org/wiki/documen ... en%20Modes

You can also create custom modes, and use alternative fonts.

No promises the editor can handle more than that... but take that with a pinch of salt. The display routines have always Just Worked, so I haven't had to delve too deeply into them.

Yes, it mostly seems to work in the higher resolution modes as well. The whole of the screen was used, and scrolling worked as expected. (I tried MODE 21, which has 80x64 text, and 256 colours)

There were a couple of minor issues:

1. When inserting lines and you get the the point where renumbering occurs, then the screen is refreshed and the cursor position has moved to a different line. Same happens if you just renumber with f4.

2. The cursor size chaning code takes effect on the host VDU, because it's manipulating the 6845 registers,

3. Using FORE in certain modes didn't work, because the Basic Editor uses a lookup table to determine the logical foreground colour to change:

Code: Select all

		LDA	#$87		; get MODE in Y
                JSR	OSBYTE		; get MODE in Y
                tya
                and #7          ;the M128 only ever returns 0-7, but I
                                ;don't know what other systems do.
                tay
                ldx fg_table,Y
		LDY	foreground_colour ; get	FORE colour

set_palette_entry:

If there's anything that can be done in the VDU driver to resolve these, I'd be happy to make that happen.

Dave

[tom_seddon]

Yes, it mostly seems to work in the higher resolution modes as well. The whole of the screen was used, and scrolling worked as expected. (I tried MODE 21, which has 80x64 text, and 256 colours)

There were a couple of minor issues:

1. When inserting lines and you get the the point where renumbering occurs, then the screen is refreshed and the cursor position has moved to a different line. Same happens if you just renumber with f4.

I had a quick poke through the code and found this routine, which accesses a 32-word table indexed by the screen row: https://github.com/tom-seddon/basic_edi ... .s65#L5982 - suggests the code might need some surgery if it's to properly support more than 32 lines on screen.

(I'm not sure what's at $700...)

2. The cursor size chaning code takes effect on the host VDU, because it's manipulating the 6845 registers,

Would it help if it used VDU 23 to do this?

3. Using FORE in certain modes didn't work, because the Basic Editor uses a lookup table to determine the logical foreground colour to change:

The easiest thing is probably to select COLOUR 1 in every mode, and then that's always the colour to change. (Looks like there's no VDU variable that holds the actual text colour index, just some encoded values which are a pain to decode.)

This discussion also makes me realise I've got a problematic change coming up: I changed the code so it changes the mode on entry, meaning it can get you out of MODEs 2 and 5. No problem; I will reinstate the old code (which is careful never to change mode, and is probably why this all works as well as it does), and just make it do a sneaky VDU 22,135 if it finds itself specifically in MODE 2 or 5 (which also covers the MODE 130 or 133 case).

--Tom

[hoglet]

I had a quick poke through the code and found this routine, which accesses a 32-word table indexed by the screen row: https://github.com/tom-seddon/basic_edi ... .s65#L5982 - suggests the code might need some surgery if it's to properly support more than 32 lines on screen.

Good find - that would definitely need to be increased. I'm surprised the issue has only showed up so far in renumber. That's probably down to my limited testing!

As the current language, Basic Editor would have &400-&7FF available to it.

I wonder if there are any line length limits? MODEs 29-32 are 100x75 and MODEs 37-40 are 112x44. I can try these tomorrow.

Would it help if it used VDU 23 to do this?

Yes, that would make it easier to intercept.

The easiest thing is probably to select COLOUR 1 in every mode, and then that's always the colour to change. (Looks like there's no VDU variable that holds the actual text colour index, just some encoded values which are a pain to decode.)

I also struggled to find a VDU variable for this. So I think this change make sense.

Having played with Basic Editor over the last few days, it really is very good. It's great that this is still being actively worked on. It's likely to become a permenant addition to my systems, and also the BeebFpga builds.

Dave

[tom_seddon]

Ah, excellent, I'm glad to hear you've become a convert. I've long liked this ROM, ever since I first encountered it at school around 1990. Despite some mystifying defaults, now fixed, I immediately found it a really nice upgrade over the ordinary copy-key-heavy basic editing experience. And so, here I still am, in 2022

I've posted a few wip bits to the wip/stuff branch in the repo:

• leave mode alone on startup - unless <40 columns, in which case select mode 135
• do an initial pass on the code to try to eliminate any mode-indexed tables. There are still some special cases for mode 7 in particular (the annoying doubled-up interlaced sync+video scanline counter affects the cursor start/end settings...) but those are handled by checking for mode number 7 specifically
• set CRTC registers using VDU 23,0
• foreground is colour 1, background is colour 0. This setting currently sticks on exit back to basic... not sure what the fix for this is. I could do a VDU 20 then COLOUR 128 then COLOUR 7, I suppose? But while that'd cover the 8-bit modes, is it good enough for the extended set?

As the branch name might suggest, this is a bit of a work in progress. I'll feel more confident about it once I've actually used it in anger for a while. But I note that it's saved a nice 40-odd bytes, as well as (hopefully) ensuring compatibility with a wider range of VDU drivers, so I'm happy.

I do still need to look into this bit of code though: https://github.com/tom-seddon/basic_edi ... .s65#L2299

I've also done nothing about the 32 row limit so far other than add a GitHub issue about it: https://github.com/tom-seddon/basic_editor/issues/24

--Tom

P.S. I wonder how much use the foreground/background colour selection actually gets. I always use the default white on black. Maybe I could strip this all out?

[hoglet]

Here's a updated PiTubeDirect build that includes the bug fixes from the last week:
https://github.com/hoglet67/PiTubeDirec ... ognose-rc6

Changes since Hognose RC5:
- PDP-11 Co Pro: Updated client rom to 0.28d
- JIT 6502: Fixed BIT &00 instruction used to save jumps in 6502 code (fixes Comal bug: #161)
- JIT 6502: Fixed some JIT Debug issues
- Frame Buffer: implement OSBYTE &A0 X=&4F/&60/&61
- Frame Buffer: fix a compile error with older gcc (?)
- Frame Buffer: VDU 23,0,10/11 controls cursor start/end row

Dave

[hoglet]

Hi all,

There have been no further issues reported since we released Hognose RC6 a couple of months ago.

So today I've merged the hognose branch back into master, and tagged it as the official Hognose release.
https://github.com/hoglet67/PiTubeDirec ... ag/hognose

Compared to Gecko, there are two main new features:
- a new JIT-based 6502 Co Pro (Co Pro 24) that is up to 4x faster than the existing non-JIT 6502 Co Pro (Co Pro 0)
- support for using the Pi as a second display, including a built-in VDU compatible framebuffer driver

For full details of what's changed since Gecko, see the release notes.

For details on the Pi framebuffer driver, see the Pi VDU Driver wiki page.

Many thanks to Dominic for all of his work on the excellent JIT-6502 Core.

Thanks also to Ed and Mincebert for their help and support with testing, and to JGH for the updated PDP-11 Client ROM.

Dave

[Vee]

Hi, I picked up Co-Pro adapter from RetroClinic a while back, and just collected a Raspberry Pi 1 from friend to use as the Co-Pro.

Looking at the wiki it says -

The following Pi Models are not currently supported:

Raspberry Pi Model A Rev. 2.0 (0007, 0008, 0009)
Raspberry Pi Model B Rev. 2.0 (0004, 0005, 0006, 000d, 000e, 000f)
The Model A/B Rev. 2.0 needs some additional work to support, as the GPIO pinout has changed. See the upcoming release (Fer-de-Lance.)

The Pi turns out to be a 000e (typical!), so the pin out is indeed different, but as we're well past Fer-de-Lance, I was wondering if this incompatibility has been fixed before I go medieval on the Pi to remove the Composite socket. Or if indeed I can fix something in the ribbon cable?

[hoglet]

The Pi turns out to be a 000e (typical!), so the pin out is indeed different, but as we're well past Fer-de-Lance, I was wondering if this incompatibility has been fixed before I go medieval on the Pi to remove the Composite socket. Or if indeed I can fix something in the ribbon cable?

As far as I'm aware, all Pi Models should work fine with the latest (Hognose) release.

Dave

[KenLowe]

The Pi turns out to be a 000e (typical!), so the pin out is indeed different, but as we're well past Fer-de-Lance, I was wondering if this incompatibility has been fixed before I go medieval on the Pi to remove the Composite socket. Or if indeed I can fix something in the ribbon cable?

I can supply a Tube level shifter with a special 26 pin header that avoids you from having to remove the composite socket from your Pi, if that's of any interest to you:

viewtopic.php?p=264180#p264180

[jgharston]

I've been pondering buying a couple/few more Pis for various projects. However, a quick look at RS and the Pi Foundation suggests all the PCB layous are sort-a L shaped. By what I mean, there are sockets EAST and SOUTH, making it fiddly to make wiring neat. With my current Pi I don't have the option of playing with the video output because the Tube cable to the Master obscures the socket:

Code: Select all

         +-----------------+
         |              USB|-------
         |                 |
         |              NET|-------
         +-----------------+
           |     |
         power video

Are there any versions where the sockets are EAST and WEST, viz something like this:

Code: Select all

         +-----------------+
power----+              USB|-------
         |                 |
video----+              NET|-------
         +-----------------+

Then it would be very easy to neatly route and contain the wires.

[scruss]

... Are there any versions where the sockets are EAST and WEST, ...

Alas, no. They're all L-shaped. I guess the Zero W and the Zero 2W aren't, but they're a whole special brand of unobtainable right now. The L-shape was an improvement on the very first Raspberry Pi, which had cables coming out of all four sides.

You're somewhat unlikely to get a Raspberry Pi from RS/OKdo. They had a falling out with Raspberry Pi Trading, and as of three months ago, are no longer a manufacturing or sales partner.

[BeebMaster]

In the Native ARM, doing *BASIC whilst already in ARMBASIC causes a crash, but doing *BASIC from the Supervisor prompt gives the expected "This is not ARM code" error:

Not sure it's a bug as such, I suppose what's happening is that it's copying BASIC from ROM over part of the memory currently being used by ARMBASIC, but it could cause problems with !Boot files which tend to do *BASIC followed by CHAIN etc. (This is how I discovered it.)

[AndyGarton]

A possibly silly question - is there any downside to leaving the VDU driver enabled in the config file (vdu=1) please? I very often have sessions where I don't use the HDMI display, and would rather not have to keep editing the config file if I don't really have to.

[hoglet]

A possibly silly question - is there any downside to leaving the VDU driver enabled in the config file (vdu=1) please?

There isn't any real disadvantage that I'm aware of.

Dave

[marcusjambler]

Hi Dave
I've got a Pi3A+ booting ( Hognose firmware).
Internal level shifter(Sunby Issue 1.4) in a Beeb Master
When I list spheres it either posts 1200Mhz/400Mhz or 600MHz/250MHz randomly.
Is this a settings issue?
Pi 3B posts 1200MHz/400MHz every time.

Marcus

[hoglet]

When I list spheres it either posts 1200Mhz/400Mhz or 600MHz/250MHz randomly.
Is this a settings issue?

It could well be a bug, but I haven't managed to reproduce it yet.

Are you power cycling in between each LIST?

Can you post a photo of LIST ,10 with it showing 600 please?

Does SPHERE actually run slower when it's showing 600?

Dave

[marcusjambler]

It changes on power cycle.
No, it hovers around 1.45 1.46
However I'm struggling to make it do it now.
I think its a pin/socket cleanliness issue.
I've got a new level shifter on order with Retroclinic so, I'll post again if it continues.
Thanks for the swift response

Marcus

[BeebMaster]

Internal level shifter(Sunby Issue 1.4) in a Beeb Master

Ouch! Been wondering what's been hurting!

[hoglet]

I think its a pin/socket cleanliness issue.

Check the power supply jumper on the level shifter is not loose, and give the pins a clean.

Can you post a photo of the LIST ,10 when it's showing 1200 then.

There are a couple of other things I want to check.

Dave

[marcusjambler]

Internal level shifter(Sunby Issue 1.4) in a Beeb Master

Ouch! Been wondering what's been hurting!

My apologies

[marcusjambler]

I think its a pin/socket cleanliness issue.

Check the power supply jumper on the level shifter is not loose, and give the pins a clean.

Can you post a photo of the LIST ,10 when it's showing 1200 then.

There are a couple of other things I want to check.

Dave

I'll give the board a thorough scrub

Boot pic attached

[hoglet]

However I'm struggling to make it do it now.

After much trying, I managed to see this once as well!

The Native ARM also reports 600MHz:

Dave