@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: think (MY personal idea) that adopting the CP/M was a management decision. However and again IMO the rest was engineers decision. Dunno, the story goes that the C128 was developed without any order/consent from management and was later deemed good enough to be a product. Similar how the C= Germany brainfart that was the broken A2000A birthed the somewhat sensible A2000B. No idea what the original plan for the Z80 in the C128 was but CP/M might have just been the least stupid use case. As for what C= could've should've done, one thigk they hated was buying in chips which they already had to do with the 68000 and worked very hard to avoid with the chips Jay had designed. Agnus was pushing beyond what MOS could do (within spec) but they somehow made it work. Might be the little and late that ECS delivered was based on that problem and might even be that the A3000-AGA was canceled/delayed because they just couldn't do and management only caved in into outsourcing Lisa when time was running out (already had run out given the C= was dead 2 years later).

Hum. Then it looks like that it was engineer's decision...


@OneTimer1

Quote:

OneTimer1 wrote: @cdimauro Quote: It's not clear to which historical period you are talking about. About the time when reading RAM in burst cycles became common.

The 68030 was already able to do it on 1987.


@kolla

Quote:

kolla wrote: @cdimauro Quote: kolla, you're supposed to be a sysadmin and those concepts (at least the last two) should be your ABC, right? I’ve been a sysadm long enough to see VirtualPC, a PC emulator for *PowerPC* macs, be bought by microsoft and end up as HyperV, now powering Azure.

Which means that it... evolved and its technology (because it's not produced anymore) is incorporated in different products and using different purposes.
Quote:

I also had a personal Vmware license from 1998.

Which runs what kind of Virtual Machines? I mean: which architectures are supported as guests and which as hosts?

This should tell you more about VMs, because this is a clear example about the topic.
Quote:

Qemu first without, then with KVM, and later again with KVM and hardware virtualization support.

QEmu evolved like VirtualPC: it's an emulator, but it switches to a virtualization software when executing binaries of the same host's architecture.

And on both emulation or virtualization side it uses virtualization and/or hypervisor technologies to accelerate the binaries execution.

In short: it can do / be both.
Quote:

Like I wrote, it’s a scale with its extremes (everything emulated to nothing emulated) and lots in between. Conceptually there’s not much difference. Like with Qemu, whether you use code that emulates a 68k in software or use code that use kvm and skips emulation, what you get is a virtual system.

If you talk generically as "virtual system", yes: they are the same.

However emulation and VMs are quite different.

BTW, some computer languages (Python, PHP, LUA, ecc.) internally use so called VMs for executing their programs. VMs is a common and generally accepted term in this context.

@cdimauro

Quote:

cdimauro wrote: @Kronos However emulation and VMs are quite different.

Mostly when it comes to the CPU. In other areas they may equally emulate a range of hardware and in this regard they are much the same.

_________________
All the way, with 68k

Quote:

cdimauro wrote: think (MY personal idea) that adopting the CP/M was a management decision.

The Real Story Of Hacking Together The Commodore C128
Quote:

My name is Bil Herd and I was that long-haired, self-educated kid who lived and dreamed electronics and, with the passion of youth, found himself designing the Commodore C-128... The team I worked with had an opportunity to slam out one last 8 bit computer, providing we accepted the fact that whatever we did had to be completed in 5 months… in time for the 1985 Consumer Electronics Show (CES) in Las Vegas. We (Commodore) could do what no other computer company of the day could easily do; we made our own Integrated Circuits (ICs) and we owned the two powerhouse ICs of the day; the 6502 microprocessor and the VIC Video Display IC. This strength would result in a powerful computer but at a cost; the custom IC’s for the C-128 would not be ready for at least 3 of the 5 months. before the custom IC’s became available, there was no choice but to Hack in order to make the deadlines. And by Hack I mean we had to create emulator boards out of LS-TTL chips... To add to the fun, a couple of weeks later the marketing department in a state of delusional denial put out a press release guaranteeing 100% compatibility with the C64.

C128 AMA from Bil Herd
Quote:

The Z80 started by me looking at two problems at roughly the same time: 1)The CPM cart was having problems with the C64, and was sensitive to the version VIC chip and also a brand of 74ls257's, 2) the CPM cart needed about another 1 to 1.5 Amp from the power supply. The C64 supply just gets hotter and the voltage drops, but the C128 being a switching supply meant that I would have had to specify and pay (times millions) for an extra 1.5 Amp that would probably seldom get used... Designing the Z80 in costed about $2, and was cheaper than the power supply increase... We didn't tell management that we had built in the Z80 until it was too late to stop us.

Commodore Marketing had wanted CP/M compatibility starting with the PET, but it wasn't until the C64 that they decided to do it, with a cartridge. The C64 was launched with a CP/M option touted on the box, but they didn't actually make the cartridge until almost a year later. Then they changed something in the VIC chip that caused the CP/M cartridge to stop working in later C64s. IIRC a customer complained to Commodore about this, and so the decree came down from Marketing that the C128 must have a fully working CP/M option.

So the decision to have CP/M in the C128 was made by the Marketing division, but Engineering made the decision to build it into the machine. The (sensible) reason for that is that it was cheaper to build it in than upgrade the PSU to handle the CP/M cartridge. Whether that was a good decision or not is debatable, but having the Z80 built in made the specs look more impressive and probably helped sales.

Last edited by bhabbott on 07-Nov-2023 at 05:42 AM.

@agami

Quote:

agami wrote: @cdimauro Quote: cdimauro wrote: @Kronos However emulation and VMs are quite different. Mostly when it comes to the CPU.

Well, the CPU is the main actor when we're talking about virtualization and, specifically, about Virtual Machine.

We should know why Motorola introduced the 68010: to fix the issue with the MOVE SR instruction which prevented the 68000 to satisfy the Popek and Goldberg virtualization requirements.

The 80386 is another good example regarding this, because it introduced specifically features to (easily) allow the (very fast) execution of 8086 Virtual Machines.

Definitions matter. At least when talking about technical things.
Quote:

In other areas they may equally emulate a range of hardware and in this regard they are much the same.

Which areas?


@bhabbott

Quote:

bhabbott wrote: Quote: cdimauro wrote: think (MY personal idea) that adopting the CP/M was a management decision. The Real Story Of Hacking Together The Commodore C128 Quote: My name is Bil Herd and I was that long-haired, self-educated kid who lived and dreamed electronics and, with the passion of youth, found himself designing the Commodore C-128... The team I worked with had an opportunity to slam out one last 8 bit computer, providing we accepted the fact that whatever we did had to be completed in 5 months… in time for the 1985 Consumer Electronics Show (CES) in Las Vegas. We (Commodore) could do what no other computer company of the day could easily do; we made our own Integrated Circuits (ICs) and we owned the two powerhouse ICs of the day; the 6502 microprocessor and the VIC Video Display IC. This strength would result in a powerful computer but at a cost; the custom IC’s for the C-128 would not be ready for at least 3 of the 5 months. before the custom IC’s became available, there was no choice but to Hack in order to make the deadlines. And by Hack I mean we had to create emulator boards out of LS-TTL chips... To add to the fun, a couple of weeks later the marketing department in a state of delusional denial put out a press release guaranteeing 100% compatibility with the C64. C128 AMA from Bil Herd Quote: The Z80 started by me looking at two problems at roughly the same time: 1)The CPM cart was having problems with the C64, and was sensitive to the version VIC chip and also a brand of 74ls257's, 2) the CPM cart needed about another 1 to 1.5 Amp from the power supply. The C64 supply just gets hotter and the voltage drops, but the C128 being a switching supply meant that I would have had to specify and pay (times millions) for an extra 1.5 Amp that would probably seldom get used... Designing the Z80 in costed about $2, and was cheaper than the power supply increase... We didn't tell management that we had built in the Z80 until it was too late to stop us. Commodore Marketing had wanted CP/M compatibility starting with the PET, but it wasn't until the C64 that they decided to do it, with a cartridge. The C64 was launched with a CP/M option touted on the box, but they didn't actually make the cartridge until almost a year later. Then they changed something in the VIC chip that caused the CP/M cartridge to stop working in later C64s. IIRC a customer complained to Commodore about this, and so the decree came down from Marketing that the C128 must have a fully working CP/M option. So the decision to have CP/M in the C128 was made by the Marketing division, but Engineering made the decision to build it into the machine. The (sensible) reason for that is that it was cheaper to build it in than upgrade the PSU to handle the CP/M cartridge. Whether that was a good decision or not is debatable, but having the Z80 built in made the specs look more impressive and probably helped sales.

No, the management wanted to have CP/M compatibility as a possibility (via cartridge). So, it was an optional add-on.

Whereas the engineers inserted the required hardware in the machine.

The "funny" thing is that they didn't talk each other...

@OneTimer1

Quote:

OneTimer1 wrote: But building PC slots into an A2000 without a possibility to access them from the 68k was totally stupid, they should have build it without them, the money could have been better invested in a slightly faster 68k or into more RAM.

A 'slightly' faster 68k wouldn't help much, and adding RAM on the motherboard would have required a complex controller. The A2000 had slots for those things, and it did come with a 1MB RAM board.

It was quite possible to have a 'bridgeboard' that simply connected the Zorro II and ISA buses together (with a few TTL chips for address decoding etc.). I made one for a friend so he could put a PC hard drive in his A2000. Worked brilliantly! Some commercial hard drives and other cards used a similar solution. The Golden Gate 2+ and Spirit AX-S were general purpose 'bridgeboards' that supported a variety of ISA cards.

However plenty of Zorro II cards were developed to suit most needs, so the 'bridgeboard' solution didn't become very popular. Zorro II cards were a safer choice because you knew they were properly designed to work in the A2000, unlike random ISA bus cards which could have compatibility issues. To keep them simple the 'bridgeboards' didn't do DMA either, which was a problem for things like PCM sound cards and floppy disk controllers. But the A2000 already had good graphics and sound etc. so there was little incentive to use ISA bus cards for those functions.

Of the 4 ISA slots in the A2000, only 2 of them are standalone. The other two are inline with Zorro II slots, so an Amiga card can use both. Some cards used in video applications etc. plugged into an ISA slot purely to get power and be inside the case. So they weren't useless.

I wish I had an A2000 so I could play around with stuff like that again. As a substitute I am thinking of making an ISA bus expansion board for my spare A500 motherboard, putting it in a custom case and using my A2000 keyboard with it. I want to try doing things like producing synth sound from an ISA sound card and chunky pixels from an ISA VGA card.

@cdimauro

Quote:

cdimauro wrote: No, the management wanted to have CP/M compatibility as a possibility (via cartridge). So, it was an optional add-on. Whereas the engineers inserted the required hardware in the machine.

YES, that's what I said!

Quote:

The "funny" thing is that they didn't talk each other...

I sense your goal here is to bash Commodore for not micro-managing hardware development from the top. Like many companies they gave their engineers a degree of flexibility in meeting design goals. Bil Herd's innovative CP/M solution was one of those examples. You may say it proves that Commodore's management was dysfunctional, but this is how a lot of companies produced great stuff. For example:-

Ken Kutaragi (designer of the Sony PlayStation)
Quote:

In 1989, he was watching his daughter play a Famicom and realized the potential that existed within video games. At that particular time, Sony's executives had no interest in video games. Thus, when Nintendo expressed the need for a sound chip for its upcoming new 16-bit system, Kutaragi accepted the offer. Working in secret, he designed the chip, the SPC700. When they found out, Sony's executives were furious. Only with Sony CEO Norio Ohga's approval was Kutaragi able to complete the chip and keep his job. Even while working with Nintendo, within Sony, gaming was still regarded as a fad. Despite this hostile atmosphere to video games, Kutaragi managed to persuade Ohga into working with Nintendo to develop a CD-ROM add-on for the Super NES which would be released alongside a Sony branded console which could play both Super NES cartridges and CD games. These efforts resulted in a device called the "Play Station"... Despite being considered a risky gamble by other Sony executives, Kutaragi once again had the support of Ohga and several years later the company released the original PlayStation. The commercial success of the PlayStation franchise makes Sony Computer Entertainment the most profitable business division of Sony.

The PlayStation was the result of one engineer whose vision clashed with management. He wasn't given any specs to work with, and had to create a prototype of his own design just to convince them to go ahead with the project. The rest, as they, is history, but without Ken Kutaragi's tenacity and willingness to work 'in secret' against management's wishes the PlayStation wouldn't have happened - a loss for Sony and for the world.

Last edited by bhabbott on 07-Nov-2023 at 12:53 PM.

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: The "funny" thing is that they didn't talk each other... I sense your goal here is to bash Commodore for not micro-managing hardware development from the top.

I sense your goal here is to continuously defend Commodore whatever they did (management, engineers).

As usual with you (and solokov on EAB: your other "clone" that behaves like that).
Quote:

Like many companies they gave their engineers a degree of flexibility in meeting design goals. Bil Herd's innovative CP/M solution was one of those examples.

Then tell more about the Motorola 6845 video chip that was ALSO ADDED to the C128 by the same gifted engineer.

Instead of enhancing the VIC-II adding the 80 column mode & high resolution and maybe something more (e.g. more sprites, or more colored sprites. A stereo SID...).
Quote:

You may say it proves that Commodore's management was dysfunctional,

No, I'm not talking about only the management here. I never gave the full responsibility to them, like many others did: to me engineers had their great responsibilities as well.
Quote:

but this is how a lot of companies produced great stuff. For example:- Ken Kutaragi (designer of the Sony PlayStation) Quote: In 1989, he was watching his daughter play a Famicom and realized the potential that existed within video games. At that particular time, Sony's executives had no interest in video games. Thus, when Nintendo expressed the need for a sound chip for its upcoming new 16-bit system, Kutaragi accepted the offer. Working in secret, he designed the chip, the SPC700. When they found out, Sony's executives were furious. Only with Sony CEO Norio Ohga's approval was Kutaragi able to complete the chip and keep his job. Even while working with Nintendo, within Sony, gaming was still regarded as a fad. Despite this hostile atmosphere to video games, Kutaragi managed to persuade Ohga into working with Nintendo to develop a CD-ROM add-on for the Super NES which would be released alongside a Sony branded console which could play both Super NES cartridges and CD games. These efforts resulted in a device called the "Play Station"... Despite being considered a risky gamble by other Sony executives, Kutaragi once again had the support of Ohga and several years later the company released the original PlayStation. The commercial success of the PlayStation franchise makes Sony Computer Entertainment the most profitable business division of Sony. The PlayStation was the result of one engineer whose vision clashed with management. He wasn't given any specs to work with, and had to create a prototype of his own design just to convince them to go ahead with the project. The rest, as they, is history, but without Ken Kutaragi's tenacity and willingness to work 'in secret' against management's wishes the PlayStation wouldn't have happened - a loss for Sony and for the world.

So, you reported a success story of a visionary engineer that had was really gifted on understanding the needs of the time and that had a great success for that.

Kudos to Kutaragi.

But you want to compare it to the ridiculous choices of (presumed) "gifted" engineers that made utterly mistakes. Right?

Do you understand that a single case CANNOT extended to the generality? It's a logical fallacy, as you should know.

By similary, you can also tell more about the engineer and/or management at Nintendo that failed to recognize the importance of a CDRom play and... gave the console market to Sony.

Or to the SEGA engineers that realized a so much complicated system like the Saturn that... gave the console market to Sony.

Do you see? A lot of visionaries, but only one succeeded. And certainly Commodore had NOT that kind of visionaries (besides the original Amiga team).

@cdimauro

Quote:

cdimauro wrote: Quote: Like many companies they gave their engineers a degree of flexibility in meeting design goals. Bil Herd's innovative CP/M solution was one of those examples. Then tell more about the Motorola 6845 video chip that was ALSO ADDED to the C128 by the same gifted engineer.

The C128 didn't had a Motorola 6845 it didn't even had a MOS 6545, it had a MOS 8563 that was designed for the computer that was planned to be built before they bought Amiga, a chip that could display an image with the resolution of 720x700 pixels in hires interlaced mode, it had a built in blitter, that didn't interfere with CPU access.

The data might give you a hint what the hardware designers as C= / MOS where able to do, but if you dig deeper you might find why they couldn't do more, the technology available at MOS was to old and they never got access to the something newer.

Last edited by OneTimer1 on 11-Nov-2023 at 08:04 PM.
Last edited by OneTimer1 on 11-Nov-2023 at 05:02 PM.

@OneTimer1

Quote:

OneTimer1 wrote: @cdimauro Quote: cdimauro wrote: Then tell more about the Motorola 6845 video chip that was ALSO ADDED to the C128 by the same gifted engineer. The C128 didn't had a Motorola 6845 it didn't even had a MOS 6545, it had a MOS 8563 that was designed for the computer that was planned to be built before they bought Amiga, a chip that could display an image with the resolution of 720x700 pixels in hires interlaced mode, it had a built in blitter, that didn't interfere with CPU access. The data might give you a hint what the hardware designers as C= / MOS where able to do, but if you dig deeper you might find why they couldn't do more, the technology available at MOS was to old and they never got access to the something newer.

OK. I was recalling badly. Probably because its registers were similar to the 6845 ones in terms of functionalities and also how to access them.

However there was no Blitter there: just a DMA channel for copying bytes from one location to another location.

Anyway, it's another mistake of Commodore's engineers: instead of adding 80 columns to the VIC-II (and high resolution, as natural consequence) and keeping a SINGLE video chip in the system, they resorted to a new one, overlay complicated to use, ALIEN to the video chips that the company developed (so, a new thing to understand how it works and how to program it), not even supported by the system (only VIC-II was OBVISIOUSLY used, since the BASIC 7.0 was just an evolution of the previous 2.0 and 3.5 ones), and with very poor yields (according to Wiki) = higher production costs.

"Kudos" to the visionaries (which maybe used something strong for having those visions)...

@cdimauro

Quote:

cdimauro wrote: However there was no Blitter there: just a DMA channel for copying bytes from one location to another location.

They called it a 'blitter', but it was designed to work with text characters so not a 'bit blit' unless you consider a whole character to be a 'pixel'. It had a limit of 256 bytes per 'blit' so it couldn't even scroll the text screen in one operation. However it was still much faster than using the CPU.

Quote:

Anyway, it's another mistake of Commodore's engineers: instead of adding 80 columns to the VIC-II (and high resolution, as natural consequence) and keeping a SINGLE video chip in the system, they resorted to a new one, overlay complicated to use, ALIEN to the video chips that the company developed

Perhaps you should read up on the history of the C128. They had only 5 months to get it ready for Winter CES, and it took 3 months to make a new VIC chip. The changes required to make it do 80 column text weren't trivial and might take several iterations to get the bugs out - time they didn't have. Commodore Germany offered them the video chip they developed for the C900, which (they said) could easily be modified to work in the C128. Of course in reality it wasn't quite that simple...

In the end having two different video chips did have one advantage - you could hook up two monitors and have a nice sharp 80 column text display and VIC composite output at the same time, great for development work.

Quote:

(so, a new thing to understand how it works and how to program it), not even supported by the system

It was only in there to do CP/M so it didn't need more OS support than that. The C64 didn't have much OS support for its hardware either, so this wasn't a surprise. C64 coders were used to it.

Quote:

and with very poor yields (according to Wiki) = higher production costs.

This was common at the time. Engineering samples had very low yields because they didn't tweak the process for the particular chip. This didn't usually matter because you had to make a lot of chips in each run anyway, so if only 1% worked it was fine. However the 8563 was a complex chip that pushed the limits of their process. They weren't the only ones to have that problem. When Motorola developed the 68020 their initial run had 0% yield too. Intel had a similar problem with their 80386DX, which initially couldn't meet its design clock rate. In production these problems are usually ironed out so the chips get cheaper.

Quote:

"Kudos" to the visionaries (which maybe used something strong for having those visions)...

Visionaries? Pah! I'm still waiting for my flying car!

Commodore's 'vision' for the C128 was to make it more attractive for 'serious' uses such as business applications and software development. In particular they wanted to woo some of the people who might be considering a low-end PC instead. This appears to have been partially successful because it sold well despite being much more expensive than the C64. The other reason for the C128 was to fill in the gap before the Amiga was ready for full-scale production.

You might not think these plans were 'visionary', but small steps are often more successful than radically new concepts. The IBM PC wasn't visionary - It was basically a copy of the Apple II but with an 8088 CPU, it's purpose being to stop Apple from cutting into their minicomputer sales. Yet it was hugely successful and spawned continuous incremental development.

Sony's PlayStation wasn't visionary either. The 3DO (designed by ex Commodore engineers Dave Needle and R. J. Mical) was released 2 years earlier. The only 'visionary' thing about the PlayStation was that they produced a console at all, since management thought video game consoles were just a 'fad' that Sony shouldn't get involved in.

@cdimauro

Quote:

an emulator, but it switches to a virtualization software when executing binaries of the same host's architecture.

Yes, exactly.

(which is what I tried to point out on that “OS4 for KVM” thread some weeks ago, where people weren’t really talking about KVM, just Qemu on amd64… excuse me… “x64”, and virtio, which isn’t KVM)

Quote:

If you talk generically as "virtual system", yes: they are the same.

Glad we agree.

Quote:

However emulation and VMs are quite different.

Like I wrote, it’s a scale. It’s not uncommon for VMs to not be fully virtualization and zero emulation. Emulation of TPM, LSI Logic scsi controllers, e1000 NIC and more. Yes, it has improved over the years, but slowly. Likewise, it’s quoite common for “emulators” to make use of resources direclty available in host OS without emulating something in particular. For example, the WinUAE native framebuffer “emulation”?


Quote:

BTW, some computer languages (Python, PHP, LUA, ecc.) internally use so called VMs for executing their programs. VMs is a common and generally accepted term in this context.

Yes, I’m of course fully aware of that. Some even would call writing java code as “coding for an emulator”

Last edited by kolla on 18-Nov-2023 at 12:43 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: However there was no Blitter there: just a DMA channel for copying bytes from one location to another location. They called it a 'blitter', but it was designed to work with text characters so not a 'bit blit' unless you consider a whole character to be a 'pixel'. It had a limit of 256 bytes per 'blit' so it couldn't even scroll the text screen in one operation. However it was still much faster than using the CPU.

Yes, but it's exactly like the DMA controller integrated on C64's big memory expansions.
Quote:

Quote: Anyway, it's another mistake of Commodore's engineers: instead of adding 80 columns to the VIC-II (and high resolution, as natural consequence) and keeping a SINGLE video chip in the system, they resorted to a new one, overlay complicated to use, ALIEN to the video chips that the company developed Perhaps you should read up on the history of the C128. They had only 5 months to get it ready for Winter CES, and it took 3 months to make a new VIC chip. The changes required to make it do 80 column text weren't trivial and might take several iterations to get the bugs out - time they didn't have.

I don't think so. It requires the video clock to run at double the speed, so having double the clock cycles per raster line and you keep almost the same logic (you should only "adjust" the beginning and end of the video output generation).

It's like what I've reported on my other article about ECS enhancements: exactly the same logic. And you can even keep the 8 hardware sprites (or even double them. Or double their colours).
Quote:

Commodore Germany offered them the video chip they developed for the C900, which (they said) could easily be modified to work in the C128. Of course in reality it wasn't quite that simple...

But then just use the C900 if they wanted to have a CP/M-capable machine: it was designed for that!
Quote:

In the end having two different video chips did have one advantage - you could hook up two monitors and have a nice sharp 80 column text display and VIC composite output at the same time, great for development work.

Yes, two independent monitors for development is a peace of cake. But at the time it was quite expensive even having a single monitor (I only used TVs with my Plus/4 and C128, and my 1200).
Quote:

Quote: (so, a new thing to understand how it works and how to program it), not even supported by the system It was only in there to do CP/M so it didn't need more OS support than that. The C64 didn't have much OS support for its hardware either, so this wasn't a surprise. C64 coders were used to it.

But C128 HAD support for the hardware. Not fully, but most of it was there.
Quote:

Quote: "Kudos" to the visionaries (which maybe used something strong for having those visions)... Visionaries? Pah! I'm still waiting for my flying car! Commodore's 'vision' for the C128 was to make it more attractive for 'serious' uses such as business applications and software development. In particular they wanted to woo some of the people who might be considering a low-end PC instead. This appears to have been partially successful because it sold well despite being much more expensive than the C64. The other reason for the C128 was to fill in the gap before the Amiga was ready for full-scale production.

Then directly release the C128D with the CP/M support, since a floppy drive was a requirement for professionals.

And keep the standalone C128 without the floppy and without the double CPU & video chips.
Quote:

Sony's PlayStation wasn't visionary either. The 3DO (designed by ex Commodore engineers Dave Needle and R. J. Mical) was released 2 years earlier. The only 'visionary' thing about the PlayStation was that they produced a console at all, since management thought video game consoles were just a 'fad' that Sony shouldn't get involved in.

Here I don't agree. The PS was designed with innovative 3D hardware and FMV which was a clear departure from what the consoles offered since then.

It was a game changes on the consoles market.

All others had to follow and who didn't has felt down (e.g. the great Nintendo with its N64 and Sega with its overlay complicated Saturn).

@kolla

Quote:

kolla wrote: @cdimauro Quote: However emulation and VMs are quite different. Like I wrote, it’s a scale. It’s not uncommon for VMs to not be fully virtualization and zero emulation. Emulation of TPM, LSI Logic scsi controllers, e1000 NIC and more. Yes, it has improved over the years, but slowly. Likewise, it’s quoite common for “emulators” to make use of resources direclty available in host OS without emulating something in particular. For example, the WinUAE native framebuffer “emulation”?

It's not a scale: emulators and VMs are very different things albeit they can share a lot.

What distinguish the latter from the former is that you run the same processor instructions at full speed with only some of them which are virtualized & trapped by the host/hypervisor.

The rest (what the trapped instructions do and/or the peripherals) can be fully emulated (it's up to what you need to do).

Think about Dosbox and the 386's VM8086 mode: this gives you the clear separation of the two things.
Quote:

Quote: BTW, some computer languages (Python, PHP, LUA, ecc.) internally use so called VMs for executing their programs. VMs is a common and generally accepted term in this context. Yes, I’m of course fully aware of that. Some even would call writing java code as “coding for an emulator”

Because... it is.

@cdimauro

Quote:

Because... it is.

Would it make sense in amigaland to treat 68k as java? A common arc for all the amigoid OSes?

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

Quote:

pixie wrote: @cdimauro Would it make sense in amigaland to treat 68k as java? A common arc for all the amigoid OSes?

Yes. That's the concept @Karlos has proposed a bunch of times, and I have to say that it makes more sense than most Amigans are prepared to accept.

_________________
All the way, with 68k

@pixie

Quote:

pixie wrote: @cdimauro Quote: Because... it is.  Would it make sense in amigaland to treat 68k as java? A common arc for all the amigoid OSes?

Well, it already is like that: 68k apps / games are the most used binaries on the post-Amiga land. Right?


@agami

Quote:

agami wrote: @pixie Quote: pixie wrote: @cdimauro Would it make sense in amigaland to treat 68k as java? A common arc for all the amigoid OSes? Yes. That's the concept @Karlos has proposed a bunch of times, and I have to say that it makes more sense than most Amigans are prepared to accept.

I don't see the problem: Amigans already use (only) 68k. By definition (Amiga is a precise and well defined platform).

@cdimauro

Quote:

Well, it already is like that: 68k apps / games are the most used binaries on the post-Amiga land. Right?

I Just saw Eon TBL Tech talk @Twitch and at a given time Andreas Fredriksson talked on how they incorporated memory protection into FS-UAE. I wondered how much functionality could be transparently added to it.

PS-Amazing Demo, amazing talk!
Tech Blog, for those interested in seeing in more detail how the demo was made.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

Quote:

pixie wrote: @cdimauro Quote: Well, it already is like that: 68k apps / games are the most used binaries on the post-Amiga land. Right? I Just saw Eon TBL Tech talk @Twitch and at a given time Andreas Fredriksson talked on how they incorporated memory protection into FS-UAE. I wondered how much functionality could be transparently added to it.

The video is too long. I've tried to go forward to reach that specific part, but I haven't found it. So, I can't evaluate the idea.

@cdimauro

Quote:

The video is too long. I've tried to go forward to reach that specific part, but I haven't found it. So, I can't evaluate the idea.

It's around 02h01m20s

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@cdimauro

Quote:

cdimauro wrote: @agami Quote: agami wrote: Yes. That's the concept @Karlos has proposed a bunch of times, and I have to say that it makes more sense than most Amigans are prepared to accept. I don't see the problem: Amigans already use (only) 68k. By definition (Amiga is a precise and well defined platform).

There are those that are still infatuated with PowerPC or the idea that an Amiga has to be different at it's core(s). Even Trevor voiced how he doesn't want the Amiga to be just a "PC".
Then you also have the ARM-port and x86-port camps, ignoring the fact that there there are no teams left to port AmigaOS to either, and MorphOS has been silent on the subject for too many years.

The concept put forward is that everything moves to 68k for the foreseeable future, and high performance needs are then met with JIT on x64 or ARM64, with some OS components progressively written for the native hardware for additional speed/features.

Write for 68k, execute (almost) anywhere.
AGA and machine specifics for older software can be emulated in software (UAE) or alternatively via FPGA.

That's a kind of "different" that is just right for me.

_________________
All the way, with 68k