General Category > LisaList2
LisaEm 1.2.7-RC4 support bug reports
stepleton:
(I've been using the last Windows release I've been able to get my hands on, which is RC3a-2020.08.24. So this may be old news.)
As a feature request (or maybe just advice on how to use a feature that's already there): is there a way to disable the emulator's requirement that there be boot media, and that the boot media look bootable?
I've got a copy of the ROM and I'd like to boot into the ROM now and then, in order to get into service mode and poke around, even if I don't have a disk attached anywhere. It's useful for experimenting with short machine code snippets.
Also, for some of my homebrew operating environments (which boot off of file images that use my bootloader_hd bootloader), the emulator doesn't think the drive is bootable, even though I mark the first tag with $AAAA in the usual spot.
rayarachelian:
--- Quote from: stepleton on February 20, 2021, 09:07:18 am ---(I've been using the last Windows release I've been able to get my hands on, which is RC3a-2020.08.24. So this may be old news.)
As a feature request (or maybe just advice on how to use a feature that's already there): is there a way to disable the emulator's requirement that there be boot media, and that the boot media look bootable?
--- End quote ---
Nope that's not been addressed. I'm pretty sure I put those guards in on purpose, but they should only be for ROMless. Can you clarify a bit? Where are you seeing this error message and for what? The ProFile, or a floppy?
rayarachelian:
So it's been a while, and I might as well mention some status bits.
Newly discovered bugs in lisafsh-tool:
Yesterday was talking to James Denton and he noticed that LisaFSH tool seems to chop off the first few bytes off a file - I suspect this is because they're in the meta data block. i.e. the metadata is the first 0x34 bytes and the rest is the actual start of the file, or something like that. (This is similar to unixen file systems where if your file data is small enough it's included in a portion of the inode, but in this case it's not in the extent file, but rather in the metadata block.)
There's another bug in LisaFSH tool where it doesn't see all the directory blocks (I think I just fixed this one, but need to test it some more.) It will still extract all the files, but names will be file-xxxx instead, and doing dir will not show the whole disk.
There's a few other old issues such as the extracted files have junk at the end because when I wrote this, I didn't know the exact file size, though I'm pretty sure Natalia Portillo has discovered the size fields and I need to add those to the code.
Bigger problems with LisaEm itself:
But there's a bigger issue that's been blocking me for about two months now. I've mostly implemented XModem code for the TerminalWx code bit. (Unfortunately I should have either pushed an RC before this or opened a branch, so now it's kinda difficult to segregate this code and do an RC release without finishing it.)
Potentially the Lisa has a maximum need for something like 16 terminal consoles. (2 for Serial A, B, 3x expansion slots, each with the possibility of 4 serial ports for the Quad Tecmar Serial Port Card or its modern Sapient clone, one more for interfacing with BLU and yet another as a console for Xenix/UniPlus/LPW.)
So I implemented the TerminalWx as a pair of 16-member arrays that use null pointers (one set for the TerminalWx window, the other for the wxFrame). I won't actually open 16 windows, but rather as one is needed a terminal is constructed at these pointers are populated with a pointer to the relative object.
Event handling:
But this causes an issue for the event handling. Events in wxWidgets are handed via macros like so:
--- Code: ---wxBEGIN_EVENT_TABLE(TerminalWxFrame, wxTerm)
EVT_TERMINAL_INPUT(TerminalWx::OnTerminalInput)
EVT_MENU(wxID_CUT, wxTextCtrl::OnCut)
EVT_MENU(wxID_COPY, wxTextCtrl::OnCopy)
EVT_MENU(wxID_PASTE, OnPaste)
EVT_MENU(wxID_SELECTALL, wxTerm::SelectAll)
EVT_MENU(ID_FileCapture,OnFileCapture)
EVT_MENU(ID_TextUpload, OnTextUpload)
EVT_MENU(ID_XMODEM_UP,OnXmodemUpload)
EVT_MENU(ID_XMODEM_DN,OnXmodemDownload)
EVT_TIMER(ID_Timer,OnTimer)
wxEND_EVENT_TABLE()
--- End code ---
So how do I tell it which of the 16 window frame event handler is to be registered? I think I might be able to extract a window ID from the event and use that as a sector, and call back the member from one of the objects in the array, but not 100% sure yet.
That's one issue.
OnXModemUpload member function is defined, but not recognized:
But this more immediate compile time error one is very maddening. It's saying it doesn't have a member function OnXmodemUpload even through it's both in the header where the class is defined and in the cpp file where it's implemented! I've even copypasta'ed the member name, and it still throws the same error. Anyone seen anything like this? What's the fix?
In the .h file I have
--- Code: ---class TerminalWxFrame: public wxFrame
{
public:
TerminalWxFrame(wxWindow* parent,wxWindowID id = -1, int port=-1);
virtual ~TerminalWxFrame();
...
void OnFileCapture(wxCommandEvent& event);
void XModemSendBlock(void);
void XModemReceiveBlock(void);
void OnTextUpload(wxCommandEvent& event);
void OnXmodemUpload(wxCommandEvent& event);
void OnXModemDownload(wxCommandEvent& event);
...
}
--- End code ---
And in the .cpp file I have the actual implementation of the OnXModemUpload method (I used to have the unused macro there but removing it didn't help):
--- Code: ---void TerminalWxFrame::OnXModemUpload(wxCommandEvent& event) //WXUNUSED(event))
{
if (xferproto) {wxMessageBox(_("Cannot start XModem upload as another file transfer operation is in progress"),_("Cannot Upload now"), wxICON_INFORMATION | wxOK); return;}
wxString openfile;
wxFileDialog open(this, wxT("Upload File with XModem:"), wxEmptyString, wxEmptyString,
"BLU files (*.dc42;*.blu;*.bin)|All (*.*)|*.*)",
(long int)wxFD_OPEN,wxDefaultPosition);
if (open.ShowModal()==wxID_OK) {
wxString filename=openfile.GetPath();
upload=fopen(CSTR(filename),"rb");
if (!upload) {wxMessageBox(_("Could not open file for upload"),_("Cannot Upload"), wxICON_INFORMATION | wxOK); return;}
...
--- End code ---
However, gcc (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0) is throwing this, and I've no idea how to go about fixing it.
--- Code: ---src/host/wxui/z8530-terminal.cpp: At global scope:
src/host/wxui/z8530-terminal.cpp:652:6: error: no declaration matches 'void TerminalWxFrame::OnXModemUpload(wxCommandEvent&)'
652 | void TerminalWxFrame::OnXModemUpload(wxCommandEvent& event) //WXUNUSED(event))
| ^~~~~~~~~~~~~~~
src/host/wxui/z8530-terminal.cpp:652:6: note: no functions named 'void TerminalWxFrame::OnXModemUpload(wxCommandEvent&)'
In file included from src/host/wxui/z8530-terminal.cpp:81:
src/host/wxui/include/terminalwx_frame.h:11:7: note: 'class TerminalWxFrame' defined here
11 | class TerminalWxFrame: public wxFrame
--- End code ---
So... uh, wtf's going on there?
stepleton:
--- Quote from: rayarachelian on February 20, 2021, 11:29:45 am ---Nope that's not been addressed. I'm pretty sure I put those guards in on purpose, but they should only be for ROMless. Can you clarify a bit? Where are you seeing this error message and for what? The ProFile, or a floppy?
--- End quote ---
Hey, sure... I've got a Windows box with a pretty conventional install of RC3a-2020.08.24. It's configured to look for the H boot ROM in a particular location, to pretend to be a 2/5, and also to have a ProFile .dc42 image hanging off of the parallel port. I've attached my lisaem.conf to this email.
Now, the ProFile .dc42 image itself is homebrew, but I know it's good (for booting at least) because LisaEm 1.2.6.2 over on my Linux box will boot it. I made the image by using the drive image generator script that comes with my hard drive bootloader. (My Lisas can boot the drive image too.) The drive image puts $AAAA in the right place inside the first sector's tag, so I don't know why the check in romless.c doesn't like it.
Precise steps:
1. Start up LisaEm
2. Select "Power Button" under "Key"
3. Lisa pops up a "ROMless Boot" dialogue asking for a boot device (even though I have a ROM file listed in the config), and I select the ProFile on the parallel port
4. A new alert box says "No bootable OS found" etc., and after that, an alert saying that the power-on failed, and that's the end of the line
I can't share the drive image I'm using just yet (hopefully soon!), but I can share the first two blocks of it, which is just the bootloader. I've attached a hexdump of the raw image data (not the .dc42), so 2*532 bytes, with the tags in the first 20 bytes of each 532-byte half.
rayarachelian:
--- Quote from: stepleton on February 20, 2021, 01:41:47 pm ---Hey, sure... I've got a Windows box with a pretty conventional install of RC3a-2020.08.24. It's configured to look for the H boot ROM in a particular location, to pretend to be a 2/5, and also to have a ProFile .dc42 image hanging off of the parallel port. I've attached my lisaem.conf to this email.
--- End quote ---
The most likely issue is that if it went to the romless code, it means the path to the ROM isn't being recognized somehow, so it should never go there - it's possible this is a logic bug, and I'll look through the code to see if that's the case, but it shouldn't ever complain about the ProFile from there if the ROM exists.
Now, if you have a recognized ROM, and the storage file for ProFile doesn't exist, it will prompt you to create it. But if it exists, and even if it's not bootable, it shouldn't care at all and it will turn on.
I might be wrong and I promise I will look, but from what's in L1 cache (i.e. wetware brain memory cells), most likely something's not right about the path to that ROM.
In terms of the ROM, if it's a split ROM dump it should rename it and stitch it back together into a single file.
I see the filename for your ROM is 341-0175-H.BIN - but I suspect this is just the "low" side of the ROM, if so, it's not going to recognize the high part and therefore won't do the right thing. I see bitsavers has ROMs with this convention. It also would need a matching 341-0176-H.BIN for the high part.
So the solution for now would be to rename those files to something like "boot-h.hi" and "boot-h.lo" as in here: https://github.com/rayarachelian/lisaem/blob/09afe9e998752d4458d8c9d1fdab2c562a4c628e/src/lisa/cpu_board/rom.c#L421 - the critical thing is the extension should end with ".lo" and ".hi" and then it will derive the name from that and merge them together into boot-h.bin.
(Bitsavers didn't exist when I wrote this code, so there's no handler for -0175/176-X and I don't think the CPU boards I had had the part number on them - or maybe they did but I didn't notice.) :)
I'll make a note of this and add some code for this case.
--- Quote from: stepleton on February 20, 2021, 01:41:47 pm ---I can't share the drive image I'm using just yet (hopefully soon!), but I can share the first two blocks of it, which is just the bootloader. I've attached a hexdump of the raw image data (not the .dc42), so 2*532 bytes, with the tags in the first 20 bytes of each 532-byte half.
--- End quote ---
Yeah, no worries, I understand not wanting to release vaporware/unstable things, and also the need to secrecy. ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version