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

[hoglet]

Hello all,

Just a quick note to say there is a second (and hopefully final) release candidade for the PiTubeDirect Hognose available here:
https://github.com/hoglet67/PiTubeDirec ... ognose-rc2

Click on the above link for the full list of changed since the last release candidate.

Dave

[Mince]

Thanks — I shall give that a whirl.

I've just noticed that issue #130 (ADFS directories having the last line overwritten) is not solved in rc2, in certain cases -- I've added a comment to the issue but it's closed and I don't know if you get a message telling you that (I don't think I can reopen it, since you created it on my behalf).

[hoglet]

I've just noticed that issue #130 (ADFS directories having the last line overwritten) is not solved in rc2, in certain cases -- I've added a comment to the issue but it's closed and I don't know if you get a message telling you that (I don't think I can reopen it, since you created it on my behalf).

I've reopened it and will have a think...

[hoglet]

Hello all,

Sorry for the brief hiatus (due to be being majorly disctracted by PDP-11 C Compiler Bugs), but here's another Hognose release candidate:
https://github.com/hoglet67/PiTubeDirec ... ognose-rc3

It includes a relatively small set of fixes, which hopefully means we are getting closer to complete:
- 6502 Co Pro: Fixed Coprocessor list for Electron (thanks Mince)
- 6502 Co Pro: Workaround for #130 (ADFS *CAT formatting) for 6502
- Native ARM Co Pro: Workaround for #130 (ADFS *CAT formatting) for Native ARM
- Native ARM Co Pro: Improve built-in command processing and help
- Null Co Pro: Reduce power while waiting to come out of Null co pro
- Pi 4: Fix UART Internal Pull resistors not being explicitely setup
- PDP-11 Co Pro: show more state on a trap

Dave

[Mince]

Thanks for this — I'll upgrade my Master and Model B PiTubes (already done my Electron as that was already in pieces on my desk!).

Regarding the Pi 3A/B+ clock adjustment due to temperature crashing: I've done lots of several hour-long stints on the Master with copro 24 since that change was applied and it's been rock solid, so thanks for that, too.

(As an aside, the *FX 151 command shown in the ARM copro with *HELP COPROS doesn't adjust to 147 on the Electron. I've logged a GitHub issue about it - whether you're that bothered is another thing!)

[hoglet]

(As an aside, the *FX 151 command shown in the ARM copro with *HELP COPROS doesn't adjust to 147 on the Electron. I've logged a GitHub issue about it - whether you're that bothered is another thing!)

The *HELP COPROS currently works in a different way:

Code: Select all

     OS_Write0(" n   Processor - *FX ");
     OS_Write0(get_elk_mode() ? "147" : "151");
     OS_Write0(",230,n\r\n");

Is the elk_mode property set in your cmdline.txt file?

Dave

[Mince]

Is the elk_mode property set in your cmdline.txt file?

No — normally it is, but I'd forgotten it, with the testing of the interim releases. That's solved simply — sorry to waste your time!

(This method looks to be nicer than the 6502 method of checking at runtime, too, but that's in there now!)

[hoglet]

(This method looks to be nicer than the 6502 method of checking at runtime, too, but that's in there now!)

That's quite amusing, as I was thinking the opposite

Dave

[KenLowe]

Hello all,

Sorry for the brief hiatus (due to be being majorly disctracted by PDP-11 C Compiler Bugs), but here's another Hognose release candidate:
https://github.com/hoglet67/PiTubeDirec ... ognose-rc3

It includes a relatively small set of fixes, which hopefully means we are getting closer to complete:
- 6502 Co Pro: Fixed Coprocessor list for Electron (thanks Mince)
- 6502 Co Pro: Workaround for #130 (ADFS *CAT formatting) for 6502
- Native ARM Co Pro: Workaround for #130 (ADFS *CAT formatting) for Native ARM
- Native ARM Co Pro: Improve built-in command processing and help
- Null Co Pro: Reduce power while waiting to come out of Null co pro
- Pi 4: Fix UART Internal Pull resistors not being explicitely setup
- PDP-11 Co Pro: show more state on a trap

Dave

All looking good here on a couple of test PiZeros .

[Mince]

Ken’s post reminded me to say the Zero 2W on my Model B has been running rc2 for lots of long sessions, too, and it’s been rock solid (although I didn’t have trouble with that one anyway).

I’ve upgraded that to rc3 and it’ll probably get a lot more use over the weekend (along with the Master and 3A+).

[hoglet]

Thanks for the feedback guys, it's very helpful to hear this.

[zolbatar]

Not sure if this is the place to ask, but I'm having a weird problem with my native ARM co-pro code. When the executable gets over 64K(ish??) it locks up when I try and load it. This is loading a USB .SSD image with DataCentre and native co-pro mode.

I'm using the template code same as beebQuake/beebScreen etc. Cross-compiled as normal, on Mac, then using DFS Explorer to update the SSD image.

Spent a bit of time on it, and maybe someone has some inspiration!

Thanks

[dp11]

First thing to try is not to use the datacentre.

[zolbatar]

I do have a 5.25" drive etc, but how do I get stuff onto it? Presumably using serial transfer?

Not used it for YONKS!

[BeebMaster]

Some versions of DFS have problems with files larger than 64K, maybe try I later version (say 2.26?):

http://bbc.nvg.org/rom/Acorn/fs/DFS.txt

Or try storing on ADFS, I think the DataCentre supports flash-memory ADFS hard discs, doesn't it?

[BigEd]

(Edit: crossed in the post...)

Maybe there's more than one way to use a Datacentre? I don't have one. But people have had problems before with a 64k file size limit:
DataCentre RAMFS 1.04 Issues

That is, it's the filesystem which is (probably) the problem.

[zolbatar]

This is very useful advice, and seems to back up what I am seeing.

There is an internal SD card based ADFS "hard drive". I did try it once and it didn't work but that might be for an another unrelated reason.

I used to use it all the time, but the constant SD card swapping got a little annoying for transferring. I'll try it later and report back.

[zolbatar]

Yes! It works perfectly, so I'll just avoid DFS from now on.

Thanks for the help, saved me a lot of time.

[hoglet]

Hi all,

Just to say there is another release candidate for Hognose available:
https://github.com/hoglet67/PiTubeDirec ... ognose-rc4

Changes since RC3:
- Native ARM Co Pro: Support OSWORD &0E sub reason 3 (#38)
- Native ARM Co Pro: Fix broken OSWORD A=&0E sub reason 1/2
- 6502 Co Pro: Updated Tube ROM from 1.10 to 1.20
- Co Pro 80x86: Increase RAM Limit to 1024KB
- Frame Buffer: Implement a native *FX command
- Frame Buffer: implement OSBYTE 163,242,N for setting line pattern length
- Native ARM: reorder *PILIFE and *PIVDU
- Frame Buffer: Use host side replication for *PIVDU 3 mode

We've also switched from building with GCC 10.3.1 to building with GCC 11.2.1. Hopefully that won't introduce any new issues.

Dave

[AndyGarton]

I’m greatly enjoying playing with my PiTubeDirect, thanks again to everybody involved in creating it. I’d like to take my playing to another level now, specifically by creating hard disk installations on my DataCentre CF card. I’ve seen mention of this in various places, but haven’t yet found any real how-tos. I’m mainly interested in doing this for the 186/DOS and Z80/CPM cores, but would also be interested in doing it for others. Can anybody help with any links or advice please?

[BeebMaster]

Here's a picture set showing how I set up a DOS hard disc on a CF drive with a Master 512:

https://www.beebmaster.co.uk/512/CFDOSPlus.html

[AndyGarton]

Thanks you, ironically I’d just found that after posting! Very helpful. I also found a similar “text version” here:

http://www.cowsarenotpurple.co.uk/bbcco ... plus2.html

… so I think I’m good to go for DOS now, looking forward to this!

[sydney]

After Tuesdays chat about which version of pitubedirect I was using I found I couldn't wait for the next release and installed hognose rc4. The output on one TV is awesome however the one I actually use with my beeb isn't so good as you can see. Itś probably the fault of the TV but thought I'd report it just in case.

It's only using the middle third of the screen. I changed to mode 2 and it was the same.
Any ideas? I'm not too concerned as I'm happy using two screens but my plan was to have both outputs on the one screen and just switch between them as needed. Unfortunately the TV that works perfectly with the pi output isn't happy with the beeb via scart as the screen regularly jumps left to right.

[hoglet]

Any ideas? I'm not too concerned as I'm happy using two screens but my plan was to have both outputs on the one screen and just switch between them as needed. Unfortunately the TV that works perfectly with the pi output isn't happy with the beeb via scart as the screen regularly jumps left to right.

It's probably a bug....

The display code reads the EDID from the monitor and tries to make an intelligent choice as to the display parameters, like overscan.

The comment next to this code says:

Code: Select all

    // TODO: this can be greatly improved!
    // It assumes you want to fill (or nearly fill) a 1280x1024 window on your physical display
    // It will work really badly with an 800x600 screen mode, say on a 1600x1200 monitor

Do you have a Pi Serial Cable (and does your level shifter have the three-pin header for this)?

If so, I could build you a version that has VDU_DEBUG to try.

Otherwise, what's the exact model number of your Monitor. We can look up it's native resolution and force the Pi to run in that mode. Actually, this might be a sensible first step.

Dave

[sydney]

The model number for the TV is a Techwood 19884HDDVD, is that any use? I don't have a pi serial cable unfortunately.

[BigEd]

Interesting... the manual says it offers a resolution of 1360x768 (among many others) but my searches indicate that the native resolution is 1366x768. (And this is apparently normal.)

Edit: just a thought, if you boot a Pi running a Linux connected to that TV, you can get the Pi to tell you the EDID information. (tvservice -d /tmp/edid.dat) (and then attach that here, or decode it online at edid.tv)

[hoglet]

The EDID data would be useful (captured as Ed has outlined)

According to the monitor manual, it does support 1920x1080, so you could try forcing the Pi to output this by adding the following lines to config.txt:

Code: Select all

hdmi_group=1
hdmi_mode=31
hdmi_ignore_edid=0xa5000080

Alternatively, change the 31 to 19 to try forcing 1280x720.

Dave

[sydney]

Edit: just a thought, if you boot a Pi running a Linux connected to that TV, you can get the Pi to tell you the EDID information. (tvservice -d /tmp/edid.dat) (and then attach that here, or decode it online at edid.tv)

I have a pi3a somewhere, I'll have a look on Sunday and if I find it I'll post that information here.

Edit: Would a standard linux PC be able to provide the required info as I have one a few feet from the master?
Edit2:

Code: Select all

hdmi_group=1
hdmi_mode=31
hdmi_ignore_edid=0xa5000080

This worked, thanks!

[hoglet]

[Edit: Would a standard linux PC be able to provide the required info as I have one a few feet from the master?

Yes, there is a linux tool called get-edid that will save the EDID data to a file.

Code: Select all

sudo apt-get install read-edid
sudo get-edid -q > edid.bin

Then just zip and upload the edid.bin file.

Edit2:
This worked, thanks!

Running at 1920x1080 is not the best resolution for your TV (both the Pi and the TV will be scaling the image)

What does hdmi_mode=19 look like? (i.e. the same as the original, or better?)

Photos are good!

Dave

[sydney]

hdmi_mode=31

hdmi_mode=19

The monitor did not like being connected to my linux pc and the background flashed on and off about once a second. The pointer was visible at all times.