Printer emulation cuts rightmost character

[Schwefelholz]

Tried this in release 3.7 on Ultimate II, 3.10a on Ultimate 64 Elite and 3.10e on Ultimate II+L:

Using Commodore MPS, Epson FX-80/JX-80, IBM Graphics or IBM Proprinter emulations, once a printed line exceeds 80 characters of length, a character is cut from the right hand side. See attached printout: 1st line misses a colon, 2nd line misses an "I" on the right hand side.

[rgc2000]

Hi. I will take a look on this. This may be a very old bug because printer code has not evolved for a long time. Thanks for reporting this.

[rgc2000]

Bug confirmed. This is my fault. The printable area is one pixel too wide : print area width is 1920 pixels but I set this value as the last point allowed while I start on pixel 0. This makes 1921 pixels and virtual printer thinks it can print 81 chars by line instead of 80. It is obvious on my print test page. Same issue with height but there is no line loss here.

[Schwefelholz]

Now that your write this: I've seen those one-pixel column characters as well in another printout.

Is this something that can make it into the next firmware? Any chance it can get fixed in the Ultimate II?

[rgc2000]

This issue has juste been fixed in my repository for all devices supporting printer. But my git branch is in version 3.9, very far behind the official 3.10e source code. I need to merge the new features in a new branch. I am not aware of what is the latest supported firmware for Ultimate-II. I can see that 3.10e can be compiled successfully for Ultimate-II in audio and double disk versions but not for gmod2 version, I don't know what's in this last one. Then I don't know if 3.10e can fit in the device. I am still using 3.9

[GideonZ]

U2 builds for all three targets here.. But.. it doesn't work. Both the 1541 emulation as well as USB host controller are broken.

Do not use the current master (3.10e) for U2.

[Schwefelholz]

As far as I'm aware, the latest official firmware for U2 is 3.7.

[rgc2000]

Yes, last official firmware for U2 is 3.7 and I can see that I am using a custom firmware 3.8 / FPGA 117 on my U2, not very official certainly unfinished work in progress inside. Version 3.9 does not load on U2, not enough room for secondary boot loader. Anyway, back porting the fix to 3.7 is easy. Gideon, you are right the three targets build for U2, my local git was not up to date.

[Schwefelholz]

That would be very cool!

Sichere Kommunikation per Kurznachricht: Threema: https://threema.ch/download oder Signal: http://sgnl.link/1CYCQQN

per E-Mail: GnuPG-Key: gpg --recv-keys 0x29AA1668 GnuPG-Fingerprint: BDB7 63C2 8A48 A6A7 25FF 6D80 C444 F8C8 29AA 1668

-- "Those who would give up essential Liberty to purchase a little temporary Safety, deserve neither Liberty nor Safety." (Benjamin Franklin)

Am 21. März 2023 00:03:16 MEZ schrieb "René" @.***>:

Yes, last official firmware for U2 is 3.7 and I can see that I am using a custom firmware 3.8 / FPGA 117 on my U2, not very official certainly unfinished work in progress inside. Version 3.9 does not load on U2, not enough room for secondary boot loader. Anyway, back porting the fix to 3.7 is easy. Gideon, you are right the three targets build for U2, my local git was not up to date.

-- Reply to this email directly or view it on GitHub: https://github.com/GideonZ/1541ultimate/issues/306#issuecomment-1477062788 You are receiving this because you authored the thread.

Message ID: @.***>

[Grrrolf]

As far as I'm aware, the latest official firmware for U2 is 3.7.

The latest firmware can be found here: https://ultimate64.com/Firmware and it is version 3.10a. There are also U2 updaters in the zip file. Networking may be broken for the U2 in this firmware, according to reports in the FB group.

[rgc2000]

@Grrrolf , you are right. I confirm that 3.10a works on both U2 and U2+ but it looks like I have a memory stick issue on U2+ when printing several pages. Sometimes the USB device goes "FAILED" and then printer is stuck and PNG files may be lost. No problem at all on firmware 3.9 with the same memory stick. But that's not what this discussion is about. And again : printer is so much faster on U2 than U2+, most of time is spent on PNG generation, in bitmap compression routine.

[daglem]

And again : printer is so much faster on U2 than U2+, most of time is spent on PNG generation, in bitmap compression routine.

@GideonZ Perhaps it would be beneficial to switch to using Nios V or another RISC-V implementation for the U2+? Ideally the U2 would use a RISC-V CPU as well, to streamline everything (IUC the U2+L will be using NEORV32).

[GideonZ]

@daglem The U2+L uses a Risc-V processor indeed, and the idea is to migrate this to the other platforms IF the logic cell count permits. This is certainly not Nios V, because if the move is made to Risc-V, I'd like to be fully independent of the shitty vendor IP lock-in.

The reason that the U2 is faster, is because it runs on a pipelined Microblaze clone. Microblaze is pure hell and a pile of dog shit, especially considering the compiler bugs and incorrect vendor libraries. The U2+ uses Nios-IIe, because people need a license for the faster Nios-IIf. This makes the U2+ slow, because Nios-IIe is really super slow. The U64 uses the Nios-IIe, and I think that with the latest change to the memory controller in V3.10e, this makes the U64 the fastest platform now. I think.. still have to do some measurements, because the U64 still does not have a data cache.

The U2+L uses the NeoRV32, which is a great VHDL only implementation, with absolutely superb documentation and JTAG debug facility! but this processor is also not optimized for speed. The benefit is, of course, that there are many implementations of Risc-V so a change can be made later which will have little to no impact on the software and compiler chain.

Overview:	Platform	CPU	Frequency	Instruction Cache	Data Cache
U2 >3.0	MBLite	50 MHz	Yes	Yes
U2+	Nios-IIe	62.5 MHz	No	No
U64	Nios-IIf	66.6 MHz	Yes	No
U2+L	NeoRV32	50 MHz	Yes	No

[daglem]

@GideonZ Sounds good! Regarding capable open source RISC-V implementations, here is a (slightly dated) report on that, in case you want to look into it later: https://www.esa.informatik.tu-darmstadt.de/assets/publications/materials/2019/heinz_reconfig19.pdf

Given that you want a VHDL implementation of RISC-V, Orca is probably quite a bit faster than NEORV32. Size may be an issue though, and it doesn't seem to be actively developed: https://github.com/vbx-aseverance/orca (and possibly other copies on GitHub).

Otherwise I know that several people are pleased with VexRiscv, which has a good performance/size ratio. This is a good bet to fit inside all the U2s, as it's very configurable. The downside (IMHO) is the dependency on Scala: https://github.com/SpinalHDL/VexRiscv

If you really want to fly, then you could possibly have a look at cva5 (aka Taiga in the report above). This is the largest of the three, and the tools you use may not be too happy about SystemVerilog: https://github.com/openhwgroup/cva5

Speaking of vendor lock-in, have you considered using GHDL + yosys and nextpnr for the U2+L, which I presume is Lattice ECP5? Perhaps GHDL + yosys and nexpnr could be used for the U2 and/or the U2+ as well, I don't know the status for the FPGAs you use there (which are they?)

[GideonZ]

@daglem This discussion does not really belong in this ticket. We should take it somewhere else.

To answer you: Yes, a VHDL implementation is very very much preferred. VHDL is by far the better language for HDL development (at least over Verilog) when it comes to structure and formality, and thus correctness. Plus, using VHDL for the CPU eliminates the need for mixed-language simulations, for which the company I work for does not have many licenses available.

Cores that are not actively developed do not have my preference. If you'd know how many hours I wasted to debug MBLite... It's really not funny! It was a poor choice back then not to use the Xilinx Microblaze, but I totally should have and I should have used a bigger FPGA to accommodate the real Xilinx CPU. Although this would not have taken away the pile of dog shit of the Microblaze GCC compiler, at least the CPU itself is stable... Imagine having a buggy C program, a buggy compiler, buggy libraries and a buggy CPU... Plus! The MBLite doesn't have JTAG debug capabilities. In fact, there are very very few RiscV implementations that also offer JTAG debugging. NeoRV32 has this, is (very) actively developed, the developer is very responsive AND it's VHDL... Reason enough for me to pick this one. My standpoint today: a CPU without a debug interface is not a CPU.

I have heard of VexRiscV indeed. But... yah.. Scala... Glad that you also see this as a downside. You see, SpinalHDL is also the invention of one guy, and maintained by this one guy, as far as I know. We looked into this from a company perspective, to see how much benefit SpinalHDL would give over plain VHDL. Considering the learning curve of SpinalHDL, we came to the conclusion that the benefit is not worth the trouble. We might be wrong on this.

Yes, I have considered GHDL + yosys, but... I think that the Diamond tools with Synopsis do a better job. Synopsis is a very well established synthesis tool. To give you an idea, Lattice Diamond also has its own synthesis module, but I can't even fit the design into the FPGA using this, haha! I haven't tested GHDL synthesis though, because it does not seem trivial to build a GHDL with synthesis support. Yosys itself seems to only focus on Verilog, so it's like *sigh*.. Why!? I am not a big fan (yet) of open source FPGA tooling, either. I have a bit of a see-then-believe attitude that some reverse engineering will do a better job than a tool that is built with all the knowledge of the internals of the chip by the company that designed the chip in the first place. It's just .. not there yet.

I am not against using vendor tooling to build the FPGA. I am against using all sort of click-and-go stuff from the vendors that lock your design to the vendor. The Ultimate design is VHDL only and is therefore quite portable and relatively easy to simulate. That said, I fail to properly maintain the simulation targets, due to a lack of time.

As for speed: it has never been my primary goal. But if we go into that direction: The CPU is only part of the equation. Improving the memory subsystem might help more than a faster CPU in the end. Think for example about burst support and caches. Ideally, you'd want both: a fast CPU with both instruction and data caches; software that is data cache aware, and a memory infrastructure that supports bursts to fill the cache lines. Take note that the NeoRV32 uses the absolute HORRIBLE Wishbone bus structure, and is NOT capable of queing multiple requests, or do bursts. One of my ideas is to change the address decoder of the MBLite to support the RiscV instruction set, OR, to improve the NeoRV32 memory bus structure to at least support concurrent I and D accesses and bursts.

[daglem]

@GideonZ I would be interested in trying out GHDL + yosys and nextpnr once you have something ready for the U2+L. Actually, the focus of yosys AFAICT isn't on Verilog, but on what happens after generation of RTLIL. IUC the GHDL yosys plugin (https://github.com/ghdl/ghdl-yosys-plugin) elaborates and simplifies VHDL to RTLIL which is passed on to yosys, and provided the plugin does a decent job on that it would be interesting to see the results (yosys uses ABC for synthesis, which is not a toy, and I believe nextpnr does a decent job as well). Who knows, you might be surprised, even though as you point out it's early days for open source FPGA tools :sweat_smile:

[rgc2000]

Considering the issue regarding the extra character cut in the right, this is solved in my branch. I am doing a merge request. #307

[GideonZ]

@GideonZ I would be interested in trying out GHDL + yosys and nextpnr once you have something ready for the U2+L.

@daglem : Not sure what you meant by "if you have something ready". The units are now shipping, so everything is in this repo, both FPGA target (u2plus_ecp5) as well as the software targets (target/software/riscv32*)

[Schwefelholz]

Great. Thank you!

[daglem]

@GideonZ I would be interested in trying out GHDL + yosys and nextpnr once you have something ready for the U2+L.

@daglem : Not sure what you meant by "if you have something ready". The units are now shipping, so everything is in this repo, both FPGA target (u2plus_ecp5) as well as the software targets (target/software/riscv32*)

I don't see any new firmware release, nor any recent tag, so I assumed it wasn't ready. Should I just use master, or did you use any particular branch / commit for the shipped U2+L firmware?

[GideonZ]

Master should work. There is no tag yet, because the changes that I needed to make for U2+L broke the U2. As soon as I get U2 up and running again, I will release and add a tag.

[rgc2000]

Platform CPU Frequency Instruction Cache Data Cache U2 >3.0 MBLite 50 MHz Yes Yes U2+ Nios-IIe 62.5 MHz No No U64 Nios-IIf 66.6 MHz Yes No U2+L NeoRV32 50 MHz Yes No

Interesting, I should try the U64. I don't have one yet, mostly because I am too lazy to find a case, keyboard, brackets and so on to mount a new computer. I will probably order you one when available, but I am not in a hurry.

[markusC64]

Master should work. There is no tag yet, because the changes that I needed to make for U2+L broke the U2. As soon as I get U2 up and running again, I will release and add a tag.

Well, I hope that includes fixing it on the U2+. 3.10e does not run nice on my C128 with the Ultimate II+ (not U2+L). While Firmware 3.10c runs perfectly nice on that system, with firmware 3.10e the C128 crashes while freezing even in 1 MHz mode.

[rgc2000]

New merge request #309 . Previous request contained unwanted VHDL code not related to the issue.

[rgc2000]

Forget merge request #309. Fix is also included in merge request #345 with much more other issues and enhancements.

[rgc2000]

Fixed in firmware 3.11